From nobody Fri May 1 10:04:57 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873073A17ED for ; Fri, 1 May 2020 10:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 xCuM6CF0fApk for ; Fri, 1 May 2020 10:04:53 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7965A3A17EA for ; Fri, 1 May 2020 10:04:49 -0700 (PDT) Received: from lhreml734-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3488379410CE5E2F9810; Fri, 1 May 2020 18:04:46 +0100 (IST) Received: from fraeml708-chm.china.huawei.com (10.206.15.36) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 1 May 2020 18:04:46 +0100 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 1 May 2020 19:04:45 +0200 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Fri, 1 May 2020 19:04:45 +0200 From: Giuseppe Fioccola To: Bob Hinden CC: Bob Hinden , IPv6 List Subject: Reply: Re: New Version Notification for draft-fz-6man-ipv6-alt-mark-08.txt Thread-Topic: Reply: Re: New Version Notification for draft-fz-6man-ipv6-alt-mark-08.txt Thread-Index: AQHWHr+X1vpQMm2lh0OTIKyJyAS3sqiRQ+OQgACeDwCAAZXJAQ== Date: Fri, 1 May 2020 17:04:45 +0000 Message-ID: References: <158823111745.23470.11211345213358147976@ietfa.amsl.com> <1ef731f4c60d40faa54267857c429b4d@huawei.com>, <5093BA5B-6C34-4B69-98E2-6B052A10D73C@gmail.com> In-Reply-To: <5093BA5B-6C34-4B69-98E2-6B052A10D73C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_bc3b4c0b57e045d39848e5d6930c5ba8huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 17:04:56 -0000 --_000_bc3b4c0b57e045d39848e5d6930c5ba8huaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bob, Thanks a lot for your review and feedback. You are right, there are still few considerations about SRH TLV just to men= tion this possibility, but we state clearly that Hop-By-Hop Options and Des= tination Options are the best and only ways. Anyway, I agree with you, this may create confusion. I will produce a new v= ersion soon and will remove any mention of using SRH TLV. Best Regards, Giuseppe ________________________________ Giuseppe Fioccola Mobile: +49-15222812418 Email: giuseppe.fioccola@huawei.com From: Bob Hinden> To: Giuseppe Fioccola> Cc: Bob Hinden>;IPv6 List= > Subject: Re: New Version Notification for draft-fz-6man-ipv6-alt-mark-08.tx= t Time: 2020-04-30 20:52:49 Giuseppe and Tianran, Good to see most of the issues discussed on the list accounted for in this = version. I continue to think it=92s inappropriate to include any mention of using th= is option in SRH TLVs. The draft is proposing to standardize its use as a= SRH TLV and includes an IANA request to allocate a code point. This was n= ot the intended use for TLVs when SRH was standardized in 6MAN. I think all mention of its use as a SRH TLV should be removed from the docu= ment. Bob > On Apr 30, 2020, at 1:36 AM, Giuseppe Fioccola wrote: > > Dear All, > We published this new revision of the draft and it includes the changes t= hat have been agreed with Bob, Ole and Magnus after the interim meeting. > In particular we have now described in detail how the alternate marking m= ethod can work for IPv6, in order to move RFC 8321 from normative to inform= ative reference. A new Section "Alternate Marking Method Operation" has bee= n introduced for this purpose. > In addition we have added more considerations about the use of HBH to add= ress the outcome of the discussion with Eric, Ole and Tom on the mailing li= st. > > We would really appreciate hearing your thoughts and inputs. > > Best Regards, > > Giuseppe and Tianran > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, April 30, 2020 9:19 AM > To: Fengwei Qin ; Giuseppe Fioccola ; Tianran Zhou ; Mauro Cocigli= o > Subject: New Version Notification for draft-fz-6man-ipv6-alt-mark-08.txt > > > A new version of I-D, draft-fz-6man-ipv6-alt-mark-08.txt > has been successfully submitted by Giuseppe Fioccola and posted to the IE= TF repository. > > Name: draft-fz-6man-ipv6-alt-mark > Revision: 08 > Title: IPv6 Application of the Alternate Marking Method > Document date: 2020-04-30 > Group: Individual Submission > Pages: 13 > URL: https://www.ietf.org/internet-drafts/draft-fz-6man-ipv6-a= lt-mark-08.txt > Status: https://datatracker.ietf.org/doc/draft-fz-6man-ipv6-alt-m= ark/ > Htmlized: https://tools.ietf.org/html/draft-fz-6man-ipv6-alt-mark-0= 8 > Htmlized: https://datatracker.ietf.org/doc/html/draft-fz-6man-ipv6-= alt-mark > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-fz-6man-ipv6-al= t-mark-08 > > Abstract: > This document describes how the Alternate Marking Method can be used > as the passive performance measurement tool in an IPv6 domain and > reports implementation considerations. It proposes how to define a > new Extension Header Option to encode alternate marking technique and > also the Segment Routing case is discussed. > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --_000_bc3b4c0b57e045d39848e5d6930c5ba8huaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Bob,
Thanks a lot = ;for your review and feedback.

You are right,&nb= sp;there are still few considerations about S= RH TLV just to mention this possibility, = ;but we state clearly that Hop-By-Hop Options=  and Destination Options are the best an= d only ways.

Anyway, I agree&n= bsp;with you, this may create confusion. I&nb= sp;will produce a new version soon and w= ill remove any mention of using SRH TLV.=

Best Regards,
Giuseppe




Giuseppe Fioccola
Mobile: +49-15222812418  =
Email: giuseppe.fioccola@huawei= .com


From: Bob Hinden<bob= .hinden@gmail.com>
To: Giuseppe Fioccola<giuseppe.fioccola@huawei.com>
Cc: Bob Hinden<bob.h= inden@gmail.com>;IPv6 List<ipv6@= ietf.org>
Subject: Re: New Version Notification for draft-fz-6man-ipv6-al= t-mark-08.txt
Time: 2020-04-30 20:52:49

Giuseppe and Tianran,

Good to see most of the issues discussed on the list accounted for in this = version.

I continue to think it=92s inappropriate to include any mention of using th= is option in SRH TLVs.   The draft is proposing to standardize it= s use as a SRH TLV and includes an IANA request to allocate a code point.&n= bsp; This was not the intended use for TLVs when SRH was standardized in 6MAN.

I think all mention of its use as a SRH TLV should be removed from the docu= ment.

Bob






> On Apr 30, 2020, at 1:36 AM, Giuseppe Fioccola <giuseppe.fioccola@h= uawei.com> wrote:
>
> Dear All,
> We published this new revision of the draft and it includes the change= s that have been agreed with Bob, Ole and Magnus after the interim meeting.=
> In particular we have now described in detail how the alternate markin= g method can work for IPv6, in order to move RFC 8321 from normative to inf= ormative reference. A new Section "Alternate Marking Method Operation&= quot; has been introduced for this purpose.
> In addition we have added more considerations about the use of HBH to = address the outcome of the discussion with Eric, Ole and Tom on the mailing= list.
>
> We would really appreciate hearing your thoughts and inputs.
>
> Best Regards,
>
> Giuseppe and Tianran
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Thursday, April 30, 2020 9:19 AM
> To: Fengwei Qin <qinfengwei@chinamobile.com>; Giuseppe Fioccola = <giuseppe.fioccola@huawei.com>; Tianran Zhou <zhoutianran@huawei.c= om>; Mauro Cociglio <mauro.cociglio@telecomitalia.it>
> Subject: New Version Notification for draft-fz-6man-ipv6-alt-mark-08.t= xt
>
>
> A new version of I-D, draft-fz-6man-ipv6-alt-mark-08.txt
> has been successfully submitted by Giuseppe Fioccola and posted to the= IETF repository.
>
> Name:         draft-fz-6man-ip= v6-alt-mark
> Revision:     08
> Title:          &nbs= p;     IPv6 Application of the Alternate Marking Method=
> Document date:        2020-04-30 > Group:          &nbs= p;     Individual Submission
> Pages:          &nbs= p;     13
> URL:           = https://www.ietf.org/internet-drafts/draft-fz-6man-ipv6-alt-mark-08.txt=
> Status:         https://datatracker.ietf.org/doc/draft-fz-6man-ipv6-alt-mark/
> Htmlized:       https://tools.ietf.org/html/draft-fz-6man-ipv6-alt-mark-08
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-fz-6man-ipv6-alt-mark
> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-fz-6man-ipv6-alt-mark-08
>
> Abstract:
>   This document describes how the Alternate Marking Method c= an be used
>   as the passive performance measurement tool in an IPv6 dom= ain and
>   reports implementation considerations.  It proposes h= ow to define a
>   new Extension Header Option to encode alternate marking te= chnique and
>   also the Segment Routing case is discussed.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission until the htmlized version and diff are available at tools.ietf.org.=
>
> The IETF Secretariat
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--_000_bc3b4c0b57e045d39848e5d6930c5ba8huaweicom_-- From nobody Fri May 1 12:23:23 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F383A1A5E for ; Fri, 1 May 2020 12:23:20 -0700 (PDT) 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, FREEMAIL_FROM=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 6x7d6FCimRJm for ; Fri, 1 May 2020 12:23:17 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 4C11D3A1A59 for ; Fri, 1 May 2020 12:23:17 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id r26so755956wmh.0 for ; Fri, 01 May 2020 12:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aktTuyS5xn0zzWWsnrfDsCcwTE4vkzM16SAzTXUO0GA=; b=eWhVrM3MOCIRDyRySGtlrixGD6jdgp+sSFKvq8QS0IX6jSo135/cXAXvFURsRafaYY 1dtwqQFWHOdEemOke0BMRFIwHGhF86VqBznjCp2QfD4OMfHg+ZUijFoc0XVEfBWIfopR BTyEz6rx1e579uSH0IWuG94rNFNgW1/ebk8GBTlDYtbAwOo7bL+MVEpgv1cet3BbyI9Y LJC245L/rsDkypn+OeZ3d5KkKXLRKJ5raOcqRbjii6fCZH5t9/3y85uIT7b4AfcQnpdl 5heN/wTcmXD1EHBztI9HfQa2alMPgjHciC9uCqyDxaioJuwTOS1fYP6+nInQccx9bcf8 bhpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aktTuyS5xn0zzWWsnrfDsCcwTE4vkzM16SAzTXUO0GA=; b=tWisvtAoj2eobcknGf0PUgsaoX5wjE9e0s3r7zVDv3xrAkm+zj+3rs/Cv6lCWaaK+d eLKq1PleynhgxuoxIA4ep+Vbw+u6oLV8LLhYy1c52cYVrdTnkg2YxLMQGnjiqYO5/L+9 mxARVdIVgOJl//LPtzhiGqIhLmBfeeZ/a1sxXXS8e4jXMQD6EzMfKovpysBP+X3NtwNU H/+GQuXL1yN75Pi51Qo+nM/0UboZEMiSCEEZEuWqZzqN5LDXoDZqhLUfEAyhHe0OhPa9 Z6JeN1ADAqRgApuP49PMnd9VVFV5DuAWD0Q/S+6Wxb4JRcqRFCr6NmLXIa8kbsSvdCHU ki7g== X-Gm-Message-State: AGi0PuYVI/NTt+LDz6kWw+afNyI+jbU5HKgdayORE43Ts9HU/Q7bywja ecKAkAbuuhFPgPUD+CcCito= X-Google-Smtp-Source: APiQypKN6SpPUy9rfMbKEj1E2bM9Lq7GgjnDJu3R3fqpukGLv09UtQTT1k8apdjxl7xURSt/BlfrQg== X-Received: by 2002:a1c:1983:: with SMTP id 125mr949818wmz.43.1588360995662; Fri, 01 May 2020 12:23:15 -0700 (PDT) Received: from ?IPv6:2601:647:5a00:ef0b:7c51:8e0d:b02f:9884? ([2601:647:5a00:ef0b:7c51:8e0d:b02f:9884]) by smtp.gmail.com with ESMTPSA id 92sm5936411wrm.71.2020.05.01.12.23.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 May 2020 12:23:14 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_04A6D03C-B557-4DA6-958A-73283FB6CEDA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: Reply: Re: New Version Notification for draft-fz-6man-ipv6-alt-mark-08.txt Date: Fri, 1 May 2020 12:23:09 -0700 In-Reply-To: Cc: Bob Hinden , IPv6 List To: Giuseppe Fioccola References: <158823111745.23470.11211345213358147976@ietfa.amsl.com> <1ef731f4c60d40faa54267857c429b4d@huawei.com> <5093BA5B-6C34-4B69-98E2-6B052A10D73C@gmail.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 19:23:22 -0000 --Apple-Mail=_04A6D03C-B557-4DA6-958A-73283FB6CEDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Giuseppe, > On May 1, 2020, at 10:04 AM, Giuseppe Fioccola = wrote: >=20 > Hi Bob, > Thanks a lot for your review and feedback. >=20 > You are right, there are still few considerations about SRH TLV just = to mention this possibility, but we state clearly that Hop-By-Hop = Options and Destination Options are the best and only ways. >=20 > Anyway, I agree with you, this may create confusion. I will produce a = new version soon and will remove any mention of using SRH TLV. Great! Thanks, Bob >=20 > Best Regards, >=20 > Giuseppe >=20 >=20 >=20 > Giuseppe Fioccola > Mobile: +49-15222812418 > Email: giuseppe.fioccola@huawei.com >=20 >=20 > From: Bob Hinden > To: Giuseppe Fioccola > Cc: Bob Hinden;IPv6 List > Subject: Re: New Version Notification for = draft-fz-6man-ipv6-alt-mark-08.txt > Time: 2020-04-30 20:52:49 >=20 > Giuseppe and Tianran, >=20 > Good to see most of the issues discussed on the list accounted for in = this version. >=20 > I continue to think it=E2=80=99s inappropriate to include any mention = of using this option in SRH TLVs. The draft is proposing to = standardize its use as a SRH TLV and includes an IANA request to = allocate a code point. This was not the intended use for TLVs when SRH = was standardized in 6MAN. >=20 > I think all mention of its use as a SRH TLV should be removed from the = document. >=20 > Bob >=20 >=20 >=20 >=20 >=20 >=20 > > On Apr 30, 2020, at 1:36 AM, Giuseppe Fioccola = wrote: > > > > Dear All, > > We published this new revision of the draft and it includes the = changes that have been agreed with Bob, Ole and Magnus after the interim = meeting. > > In particular we have now described in detail how the alternate = marking method can work for IPv6, in order to move RFC 8321 from = normative to informative reference. A new Section "Alternate Marking = Method Operation" has been introduced for this purpose. > > In addition we have added more considerations about the use of HBH = to address the outcome of the discussion with Eric, Ole and Tom on the = mailing list. > > > > We would really appreciate hearing your thoughts and inputs. > > > > Best Regards, > > > > Giuseppe and Tianran > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Thursday, April 30, 2020 9:19 AM > > To: Fengwei Qin ; Giuseppe Fioccola = ; Tianran Zhou ; = Mauro Cociglio > > Subject: New Version Notification for = draft-fz-6man-ipv6-alt-mark-08.txt > > > > > > A new version of I-D, draft-fz-6man-ipv6-alt-mark-08.txt > > has been successfully submitted by Giuseppe Fioccola and posted to = the IETF repository. > > > > Name: draft-fz-6man-ipv6-alt-mark > > Revision: 08 > > Title: IPv6 Application of the Alternate Marking = Method > > Document date: 2020-04-30 > > Group: Individual Submission > > Pages: 13 > > URL: = https://www.ietf.org/internet-drafts/draft-fz-6man-ipv6-alt-mark-08.txt > > Status: = https://datatracker.ietf.org/doc/draft-fz-6man-ipv6-alt-mark/ > > Htmlized: = https://tools.ietf.org/html/draft-fz-6man-ipv6-alt-mark-08 > > Htmlized: = https://datatracker.ietf.org/doc/html/draft-fz-6man-ipv6-alt-mark > > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-fz-6man-ipv6-alt-mark-08 > > > > Abstract: > > This document describes how the Alternate Marking Method can be = used > > as the passive performance measurement tool in an IPv6 domain and > > reports implementation considerations. It proposes how to define = a > > new Extension Header Option to encode alternate marking technique = and > > also the Segment Routing case is discussed. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. > > > > The IETF Secretariat > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- --Apple-Mail=_04A6D03C-B557-4DA6-958A-73283FB6CEDA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl6sdx0ACgkQrut0EXfn u6iJFgf6Ah+6pLR00zM6a/BKlZZYqQ/LKhxnQZXVcanMTybmvUD/UAtZBIhil+R6 1n7C7SFyL9HKz2xuSeFtmnSJITFDFp8u9bRosRi13o6LHua4v0bugJeTo01PeuB7 VzQozhy/ri13vonvlf8vboaMqaoD67X38KK1mw1B3gZSSnSV4tuRyZy5dzRB2dsd W/SPF2zMCpbNMj8/wrL9rbF19NmPZJrD3eOzfcFicVRgjmAFAXShtA82m1xf/zW4 1C7mImNZj1hA+gqpGgK+nGSITBcyeMFFdFGyAhIklpy9d0K9SXnO4yuGHhpS44u5 9oMjaStPtpubwW7BzVFQs2M87pSnWA== =LQQr -----END PGP SIGNATURE----- --Apple-Mail=_04A6D03C-B557-4DA6-958A-73283FB6CEDA-- From nobody Sun May 3 00:38:45 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA973A16BA for ; Sun, 3 May 2020 00:38:43 -0700 (PDT) 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 IOmhxmJPEFQL for ; Sun, 3 May 2020 00:38:41 -0700 (PDT) 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 93CCF3A16B6 for ; Sun, 3 May 2020 00:38:41 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id nv1so11223459ejb.0 for ; Sun, 03 May 2020 00:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HUtwzEv/coLVYfb6c7LYaO7B64T53o6J+a2h80NDV9M=; b=MRCM0yvW1PMBEFWwf5rNaJoxn9EsGQIvLZUy9WN3DjMkQeH80v/zfG+GMBUN3Cuicj xs0QjBeWH/RIzxUaDCcxIlpfVYUslqAMedBynMExVuLvFlJSV4KuJm04KHALwx9RBxqW B0op84EuQL30zjm0KTYZ3JkC0zkgxh/EUD1K9L9lEXcTH+yhfJihRuf0ateGpClAzCwM mwJLdjxIDQkjL6xvlN0+o3I5gx+qz0p/GPADuasq5W9L6lMkT8HodrFHmPhUCQaUKa8d cht3c/K9J0c6UmaXZ6Qr+yXjc1BGCzV16H52xIQDaMn+ocutWe6XJXi1bKH4EGD1ae9Y EwJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HUtwzEv/coLVYfb6c7LYaO7B64T53o6J+a2h80NDV9M=; b=i38/hMlqqnO8ll+NH6hOCFBgj95C73t+TGJMVHttxVJDUR+ZaaIzwZvNpiz4/vU8L1 9egBc2b7zhg6kTtGxi0dBDtvXhtDOvHIr6AJNyZgzGwr3/YBAD3RjXzUD8geZZ76t249 +3mnZ/ZM5+eezf9GF0dpK+K8r2lAgxRDJM9srb02IPUEzRHXA3f2czvBfkIruceg7hgd XLhsU/SJx7oak24JqUWVvdo2G+UwGcp/ipGOfAOp/W7z95lyXoDzm1DBDD4YTxGDnD9/ jPbuGDut668J5JkDrWCHgcdynKJqoBw22spCVx3djU+tjYB0ncZ/p6hIHekVTUe4fYsq A/Vw== X-Gm-Message-State: AGi0PuZ0q94T9mKtjJHQwkHHHwFJxxb3PQh8lPJQaf8zSeeo6edrzvH2 RTANoZWNu2rIbV25VEfCKv8H3J7NjLZIskUQWR5nYlQrDUQ= X-Google-Smtp-Source: APiQypINlSO1y4JQJt1MWo/O10We1aL5SimoZ651XUW5gfdiTf8asAkw1DE2Ty6jUB1ND86qZxXACzUGazt+wqrbA34= X-Received: by 2002:a17:906:85d3:: with SMTP id i19mr9730676ejy.153.1588491519501; Sun, 03 May 2020 00:38:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: prabhakar lakhera Date: Sun, 3 May 2020 00:38:28 -0700 Message-ID: Subject: Re: RFC 7527 Optimistic Duplicate Address Detection (DAD) for IPv6 and Address Resolution To: ipv6@ietf.org Content-Type: multipart/alternative; boundary="000000000000bfa78c05a4b980a0" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 07:38:44 -0000 --000000000000bfa78c05a4b980a0 Content-Type: text/plain; charset="UTF-8" I have to correct myself here. RFC 4861 does mandate sending SLLAO for multicast NS (which would be the case for address resolution here) and that does make sense. While it is definitely desired, I am not sure how can we resolve the stated issue below without relaxing that requirement. One could modify the requirement that multicast NS with source that is preferred MUST send SLLAO. And RFC 7527 could relax the requirement and allow for sending multicast NS for address resolution with optimistic address which MUST not include SLLAO. It does imply that for the scenario below, responding to such multicast NS with an unicast NA would in turn trigger another address resolution but that is not very different from when unicast NS may miss SLLAO and the target doesn't have NS's source entry in its neighbor cache. It would still result in establishing the data path faster than waiting for DAD to complete. I am not sure, how else it could be solved other than a more complicated work around of requiring such APs to advertise RA with SLLAOs even when they are not providing any IPv6 kind of routing. On Tue, Apr 28, 2020 at 6:26 PM prabhakar lakhera < prabhakar.lakhera@gmail.com> wrote: > Hi, >> >> Wanted to check if this behavior outlined in RFC 7527 is too restrictive. >> >> https://www.rfc-editor.org/rfc/rfc4429.html#section-3.2 >> >> Specifically: >> >> * (modifies section 7.2.2 ) A node MUST NOT use an Optimistic Address >> as the source address of a Neighbor Solicitation. >> >> >> The reasoning is detailed here: >> >> https://www.rfc-editor.org/rfc/rfc4429.html#section-2.2 >> >> " In order to avoid interference, it is important that an Optimistic Node >> does not send any messages from an Optimistic Address >> that will override its neighbors' Neighbor Cache (NC) entries for the >> address it is trying to configure: doing so would disrupt the >> rightful owner of the address in the case of a collision." >> >> >> It then goes on to list the following: >> >> >> * Never sending Neighbor Solicitations from an Optimistic Address. >> NSes include a Source Link-Layer Address Option (SLLAO), which >> may cause Neighbor Cache disruption. NSes sent as part of DAD >> are sent from the unspecified address, without a SLLAO. >> >> >> That seems somewhat limiting. >> >> >> Take the scenario of a client device connecting to another device that acts as an Access point without >> >> really providing routing (say a thermal camera device, android auto/car play head unit or some other smart device). >> >> >> Right now, this would be the sequence: >> >> >> 1. Interface comes up >> >> 2. Client attached to device acting as WiFi access point. >> >> 3. Both sides configure LLA pretty quickly. >> >> 4. Client uses multicast service discovery to get the LLA endpoint of the device. >> >> 5. Client attempts connect to the device's endpoint. Optimistic DAD implies, the address can be used. >> >> 6. Outgoing TCP SYN from client will trigger address resolution, and it will be queued pending address resolution completion. >> >> 7. Even though client LLA is optimistic, because it is the only address available and the device isn't sending RA with SLLAO or NS, >> >> the neighbor cache entry at Client for Device would stay in INCOMPLETE state and no NS will be sent out from client, till address >> >> moves from optimistic to preferred. >> >> 8. 7 Implies a wait time of DAD attempts * DAD interval >> >> >> That runs in seconds and that delay is visible to user. >> >> >> Given that source link layer information is optional in NS, wouldn't just mandating that SLLAO doesn't get sent in NS from client, >> >> be enough to not cause any disruptions rather than not allowing NS to be sent at all? >> >> >> Or may be I am missing something here. Looking forward to hear some feedback on this. >> >> >> Thanks! >> >> >> Prabhakar >> >> >> --000000000000bfa78c05a4b980a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have to correct myself here.

RFC 4861 does mandate sending SLLAO=C2=A0for multicast NS (which would b= e the case for address resolution here) and that does make sense.
While it is definitely desired, I am not sure how can we resolve the state= d issue below without relaxing that requirement.

O= ne could=C2=A0modify the requirement that multicast NS with source that is = preferred MUST send SLLAO.
And=C2=A0RFC 7527 could relax the requ= irement and allow for sending multicast NS for address resolution with opti= mistic address which MUST not include SLLAO.

It do= es imply that for the scenario below, responding to such multicast NS with = an unicast NA would in turn trigger another address resolution but that is = not very different from when unicast NS may miss SLLAO and the target doesn= 't have NS's source entry in its neighbor cache.

It would still result in establishing the data path faster than wait= ing for DAD to complete.

I am not sure, how else i= t could be solved other than a more complicated work around of requiring su= ch APs to advertise RA with SLLAOs even when they are not providing any IPv= 6 kind of routing.

On Tue, Apr 28, 2020 at 6:26 PM prabhakar lak= hera <prabhakar.lakhera@g= mail.com> wrote:
Hi,

Wanted to check if this behavior outlined=C2=A0in RFC 7527 is too rest= rictive.


Specif= ically:

=
* (modifies s=
ection 7.2.2)  A node MUST NOT use an Optimistic Address
as the source address of a Neighbor Solicitation.

The reasoning is detailed here:
=

<= /div>
" In order to avoid interference, it is important that an Optimis= tic=C2=A0Node does not send any = messages from an Optimistic Address
=C2=A0 that will=C2= =A0override its neighbors' N= eighbor Cache (NC) entries for the address=C2=A0it is trying to configure: doing so would disrupt the
=C2=A0 rightful owner=C2=A0of the address in the case of a collision."

It then goes on to list the following:

   * Never sending Neighbor Solicitations from an Optimistic=
 Address.
     NSes include a Source Link-Layer Address Option (SLLAO), which
     may cause Neighbor Cache disruption.  NSes sent as part of DAD
     are sent from the unspecified address, without a SLLAO.

That seems somewhat=
 limiting.

Take the scenario of a=
 client device connecting to another device that acts as an Access point wi=
thout
really provid=
ing routing (say a thermal camera device, android auto/car play head unit o=
r some other smart device).

Right=
 now, this would be the sequence:

1. Interface comes up
2. Client attached to device acting as WiFi access point.
<= pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef= ore:page">3. Both sides configure LLA pret= ty quickly.
4. Clie=
nt uses multicast service discovery to get the LLA endpoint of the device.<=
/font>
5. Client attempts =
connect to the device's endpoint. Optimistic DAD implies, the address c=
an be used.
6. Outg=
oing TCP SYN from client will trigger address resolution, and it will be qu=
eued pending address resolution completion.
7. Even though client LLA is optimistic, because i=
t is the only address available and the device isn't sending RA with SL=
LAO or NS,
    the =
neighbor cache entry at Client for Device would stay in INCOMPLETE state an=
d no NS will be sent out from client, till address
    moves from optimistic to preferred.
8. 7 Implies a wait =
time of DAD attempts * DAD interval

That runs in seconds and that delay is visible to user.

Given that sou=
rce link layer information is optional in NS, wouldn't just mandating t=
hat SLLAO doesn't get sent in NS from client,
be enough to not cause any disruptions rathe=
r than not allowing NS to be sent at all?

=
Or may be I am missing somethin=
g here. Looking forward to hear some feedback on this.

Thanks!

Pr=
abhakar

--000000000000bfa78c05a4b980a0-- From nobody Mon May 4 01:00:45 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA85B3A005C for ; Mon, 4 May 2020 01:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vo2Dv0tfBRQS for ; Mon, 4 May 2020 01:00:42 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F043A005B for ; Mon, 4 May 2020 01:00:42 -0700 (PDT) Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 43B8A4E11BF3; Mon, 4 May 2020 08:00:42 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 8EE323347A6D; Mon, 4 May 2020 10:00:40 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Agenda for 6man Interim meeting on 5 May 2020 From: otroan@employees.org In-Reply-To: Date: Mon, 4 May 2020 10:00:40 +0200 Cc: Bob Hinden Content-Transfer-Encoding: quoted-printable Message-Id: <63F07939-9133-497E-9BD9-BA02D649AF20@employees.org> References: To: 6man WG X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 08:00:44 -0000 Presentations (we have received so far) are available at: https://datatracker.ietf.org/meeting/interim-2020-6man-02/session/6man Feel free to review before the meeting, so we can spend more time on = discussions. Best regards, Ole > On 30 Apr 2020, at 22:52, Bob Hinden wrote: >=20 > The agenda for the meeting can be found at: >=20 > = https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/agenda= -interim-2020-6man-02-6man-01.html >=20 > Time: 15:00 - 16:59 PDT, 5 May 2020 / 22:00 - 23:59 UTC, 5 May 2020 >=20 > Webex info: >=20 > = https://ietf.webex.com/ietf/j.php?MTID=3Dmfb47282545035a32e6894000fc1fe9ae= > Meeting number (access code): 614 075 168 > Meeting password: 7yTjrtbnT72 >=20 > We are looking for a minute taker and jabber scribe. >=20 > Speakers please send us a PDF of your slides by Monday 4 May 2020 = 17:00 UTC. >=20 > Bob & Ole >=20 >=20 From nobody Mon May 4 01:56:25 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74D53A0408 for ; Mon, 4 May 2020 01:56:24 -0700 (PDT) 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_H4=0.001, RCVD_IN_MSPIKE_WL=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 EweT_M95XqrV for ; Mon, 4 May 2020 01:56:22 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6406D3A0406 for ; Mon, 4 May 2020 01:56:22 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 15AFAC57523554FF70D7; Mon, 4 May 2020 09:56:21 +0100 (IST) Received: from fraeml707-chm.china.huawei.com (10.206.15.35) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 4 May 2020 09:56:20 +0100 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 4 May 2020 10:56:20 +0200 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Mon, 4 May 2020 10:56:20 +0200 From: Giuseppe Fioccola To: Bob Hinden CC: IPv6 List Subject: RE: Reply: Re: New Version Notification for draft-fz-6man-ipv6-alt-mark-08.txt Thread-Topic: Reply: Re: New Version Notification for draft-fz-6man-ipv6-alt-mark-08.txt Thread-Index: AQHWHr+X1vpQMm2lh0OTIKyJyAS3sqiRQ+OQgACeDwCAAZXJAYAABSOAgAQoV3A= Date: Mon, 4 May 2020 08:56:20 +0000 Message-ID: <82c05656eccf49dfbfbe280157ba45bc@huawei.com> References: <158823111745.23470.11211345213358147976@ietfa.amsl.com> <1ef731f4c60d40faa54267857c429b4d@huawei.com> <5093BA5B-6C34-4B69-98E2-6B052A10D73C@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.168.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 08:56:25 -0000 SGkgQm9iLA0KV2UgaGF2ZSBqdXN0IHB1Ymxpc2hlZCB0aGUgLTA5IHZlcnNpb24gd2l0aCB0aGUg YWdyZWVkIG1vZGlmaWNhdGlvbnMuDQoNClJlZ2FyZHMsDQoNCkdpdXNlcHBlDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCb2IgSGluZGVuIFttYWlsdG86Ym9iLmhpbmRlbkBn bWFpbC5jb21dIA0KU2VudDogRnJpZGF5LCBNYXkgMSwgMjAyMCA5OjIzIFBNDQpUbzogR2l1c2Vw cGUgRmlvY2NvbGEgPGdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5jb20+DQpDYzogQm9iIEhpbmRl biA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+OyBJUHY2IExpc3QgPGlwdjZAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogUmVwbHk6IFJlOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZ6 LTZtYW4taXB2Ni1hbHQtbWFyay0wOC50eHQNCg0KR2l1c2VwcGUsDQoNCj4gT24gTWF5IDEsIDIw MjAsIGF0IDEwOjA0IEFNLCBHaXVzZXBwZSBGaW9jY29sYSA8Z2l1c2VwcGUuZmlvY2NvbGFAaHVh d2VpLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBCb2IsDQo+IFRoYW5rcyBhIGxvdCBmb3IgeW91ciBy ZXZpZXcgYW5kIGZlZWRiYWNrLg0KPiANCj4gWW91IGFyZSByaWdodCwgdGhlcmUgYXJlIHN0aWxs IGZldyBjb25zaWRlcmF0aW9ucyBhYm91dCBTUkggVExWIGp1c3QgdG8gbWVudGlvbiB0aGlzIHBv c3NpYmlsaXR5LCBidXQgd2Ugc3RhdGUgY2xlYXJseSB0aGF0IEhvcC1CeS1Ib3AgT3B0aW9ucyBh bmQgRGVzdGluYXRpb24gT3B0aW9ucyBhcmUgdGhlIGJlc3QgYW5kIG9ubHkgd2F5cy4NCj4gDQo+ IEFueXdheSwgSSBhZ3JlZSB3aXRoIHlvdSwgdGhpcyBtYXkgY3JlYXRlIGNvbmZ1c2lvbi4gSSB3 aWxsIHByb2R1Y2UgYSBuZXcgdmVyc2lvbiBzb29uIGFuZCB3aWxsIHJlbW92ZSBhbnkgbWVudGlv biBvZiB1c2luZyBTUkggVExWLg0KDQpHcmVhdCENCg0KVGhhbmtzLA0KQm9iDQoNCj4gDQo+IEJl c3QgUmVnYXJkcywNCj4gDQo+IEdpdXNlcHBlDQo+IA0KPiANCj4gDQo+IEdpdXNlcHBlIEZpb2Nj b2xhDQo+IE1vYmlsZTogKzQ5LTE1MjIyODEyNDE4DQo+IEVtYWlsOiBnaXVzZXBwZS5maW9jY29s YUBodWF3ZWkuY29tDQo+IA0KPiANCj4gRnJvbTogQm9iIEhpbmRlbjxib2IuaGluZGVuQGdtYWls LmNvbT4NCj4gVG86IEdpdXNlcHBlIEZpb2Njb2xhPGdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5j b20+DQo+IENjOiBCb2IgSGluZGVuPGJvYi5oaW5kZW5AZ21haWwuY29tPjtJUHY2IExpc3Q8aXB2 NkBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig DQo+IGRyYWZ0LWZ6LTZtYW4taXB2Ni1hbHQtbWFyay0wOC50eHQNCj4gVGltZTogMjAyMC0wNC0z MCAyMDo1Mjo0OQ0KPiANCj4gR2l1c2VwcGUgYW5kIFRpYW5yYW4sDQo+IA0KPiBHb29kIHRvIHNl ZSBtb3N0IG9mIHRoZSBpc3N1ZXMgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0IGFjY291bnRlZCBmb3Ig aW4gdGhpcyB2ZXJzaW9uLg0KPiANCj4gSSBjb250aW51ZSB0byB0aGluayBpdOKAmXMgaW5hcHBy b3ByaWF0ZSB0byBpbmNsdWRlIGFueSBtZW50aW9uIG9mIHVzaW5nIHRoaXMgb3B0aW9uIGluIFNS SCBUTFZzLiAgIFRoZSBkcmFmdCBpcyBwcm9wb3NpbmcgdG8gc3RhbmRhcmRpemUgaXRzIHVzZSBh cyBhIFNSSCBUTFYgYW5kIGluY2x1ZGVzIGFuIElBTkEgcmVxdWVzdCB0byBhbGxvY2F0ZSBhIGNv ZGUgcG9pbnQuICBUaGlzIHdhcyBub3QgdGhlIGludGVuZGVkIHVzZSBmb3IgVExWcyB3aGVuIFNS SCB3YXMgc3RhbmRhcmRpemVkIGluIDZNQU4uDQo+IA0KPiBJIHRoaW5rIGFsbCBtZW50aW9uIG9m IGl0cyB1c2UgYXMgYSBTUkggVExWIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIGRvY3VtZW50 Lg0KPiANCj4gQm9iDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ID4gT24gQXByIDMwLCAyMDIw LCBhdCAxOjM2IEFNLCBHaXVzZXBwZSBGaW9jY29sYSA8Z2l1c2VwcGUuZmlvY2NvbGFAaHVhd2Vp LmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBEZWFyIEFsbCwNCj4gPiBXZSBwdWJsaXNoZWQgdGhpcyBu ZXcgcmV2aXNpb24gb2YgdGhlIGRyYWZ0IGFuZCBpdCBpbmNsdWRlcyB0aGUgY2hhbmdlcyB0aGF0 IGhhdmUgYmVlbiBhZ3JlZWQgd2l0aCBCb2IsIE9sZSBhbmQgTWFnbnVzIGFmdGVyIHRoZSBpbnRl cmltIG1lZXRpbmcuDQo+ID4gSW4gcGFydGljdWxhciB3ZSBoYXZlIG5vdyBkZXNjcmliZWQgaW4g ZGV0YWlsIGhvdyB0aGUgYWx0ZXJuYXRlIG1hcmtpbmcgbWV0aG9kIGNhbiB3b3JrIGZvciBJUHY2 LCBpbiBvcmRlciB0byBtb3ZlIFJGQyA4MzIxIGZyb20gbm9ybWF0aXZlIHRvIGluZm9ybWF0aXZl IHJlZmVyZW5jZS4gQSBuZXcgU2VjdGlvbiAiQWx0ZXJuYXRlIE1hcmtpbmcgTWV0aG9kIE9wZXJh dGlvbiIgaGFzIGJlZW4gaW50cm9kdWNlZCBmb3IgdGhpcyBwdXJwb3NlLg0KPiA+IEluIGFkZGl0 aW9uIHdlIGhhdmUgYWRkZWQgbW9yZSBjb25zaWRlcmF0aW9ucyBhYm91dCB0aGUgdXNlIG9mIEhC SCB0byBhZGRyZXNzIHRoZSBvdXRjb21lIG9mIHRoZSBkaXNjdXNzaW9uIHdpdGggRXJpYywgT2xl IGFuZCBUb20gb24gdGhlIG1haWxpbmcgbGlzdC4NCj4gPg0KPiA+IFdlIHdvdWxkIHJlYWxseSBh cHByZWNpYXRlIGhlYXJpbmcgeW91ciB0aG91Z2h0cyBhbmQgaW5wdXRzLg0KPiA+DQo+ID4gQmVz dCBSZWdhcmRzLA0KPiA+DQo+ID4gR2l1c2VwcGUgYW5kIFRpYW5yYW4NCj4gPg0KPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBB cHJpbCAzMCwgMjAyMCA5OjE5IEFNDQo+ID4gVG86IEZlbmd3ZWkgUWluIDxxaW5mZW5nd2VpQGNo aW5hbW9iaWxlLmNvbT47IEdpdXNlcHBlIEZpb2Njb2xhIA0KPiA+IDxnaXVzZXBwZS5maW9jY29s YUBodWF3ZWkuY29tPjsgVGlhbnJhbiBaaG91IA0KPiA+IDx6aG91dGlhbnJhbkBodWF3ZWkuY29t PjsgTWF1cm8gQ29jaWdsaW8gDQo+ID4gPG1hdXJvLmNvY2lnbGlvQHRlbGVjb21pdGFsaWEuaXQ+ DQo+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gPiBkcmFmdC1m ei02bWFuLWlwdjYtYWx0LW1hcmstMDgudHh0DQo+ID4NCj4gPg0KPiA+IEEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1mei02bWFuLWlwdjYtYWx0LW1hcmstMDgudHh0DQo+ID4gaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHaXVzZXBwZSBGaW9jY29sYSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+ID4NCj4gPiBOYW1lOiAgICAgICAgIGRyYWZ0LWZ6LTZt YW4taXB2Ni1hbHQtbWFyaw0KPiA+IFJldmlzaW9uOiAgICAgMDgNCj4gPiBUaXRsZTogICAgICAg ICAgICAgICAgSVB2NiBBcHBsaWNhdGlvbiBvZiB0aGUgQWx0ZXJuYXRlIE1hcmtpbmcgTWV0aG9k DQo+ID4gRG9jdW1lbnQgZGF0ZTogICAgICAgIDIwMjAtMDQtMzANCj4gPiBHcm91cDogICAgICAg ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gUGFnZXM6ICAgICAgICAgICAgICAg IDEzDQo+ID4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1mei02bWFuLWlwdjYtYWx0LW1hcmstMDgudHh0DQo+ID4gU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZ6LTZtYW4taXB2Ni1h bHQtbWFyay8NCj4gPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWZ6LTZtYW4taXB2Ni1hbHQtbWFyay0wOA0KPiA+IEh0bWxpemVkOiAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWZ6LTZtYW4taXB2Ni1hbHQt bWFyaw0KPiA+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtZnotNm1hbi1pcHY2LWFsdC1tYXJrLTA4DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4g PiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0aGUgQWx0ZXJuYXRlIE1hcmtpbmcgTWV0 aG9kIGNhbiBiZSB1c2VkDQo+ID4gICBhcyB0aGUgcGFzc2l2ZSBwZXJmb3JtYW5jZSBtZWFzdXJl bWVudCB0b29sIGluIGFuIElQdjYgZG9tYWluIGFuZA0KPiA+ICAgcmVwb3J0cyBpbXBsZW1lbnRh dGlvbiBjb25zaWRlcmF0aW9ucy4gIEl0IHByb3Bvc2VzIGhvdyB0byBkZWZpbmUgYQ0KPiA+ICAg bmV3IEV4dGVuc2lvbiBIZWFkZXIgT3B0aW9uIHRvIGVuY29kZSBhbHRlcm5hdGUgbWFya2luZyB0 ZWNobmlxdWUgYW5kDQo+ID4gICBhbHNvIHRoZSBTZWdtZW50IFJvdXRpbmcgY2FzZSBpcyBkaXNj dXNzZWQuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCj4gPg0KPiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4NCj4gPg0KPiA+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlw djZAaWV0Zi5vcmcgQWRtaW5pc3RyYXRpdmUgDQo+ID4gUmVxdWVzdHM6IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Tue May 5 17:51:21 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF57E3A0C97 for ; Tue, 5 May 2020 17:51:19 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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, 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=MyOWCbtJ; dkim=pass (1024-bit key) header.d=juniper.net header.b=frRrNPOq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMYg9C5WZrhB for ; Tue, 5 May 2020 17:51:17 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B733A0C92 for <6man@ietf.org>; Tue, 5 May 2020 17:51:16 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0460g1Ku021016 for <6man@ietf.org>; Tue, 5 May 2020 17:51:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=Uu54kOsJmpXUdNXY2J8tGgOIAHakyDk9m6qRJwZJv+s=; b=MyOWCbtJ4lcB0N1B0T7JAi9MQurLmDbgc1ujcFllNy3fgePWyLFWapYdDT3AlCpXTKGQ JIFKka5WM9t6bZ3RfPmGvBo6NIgyjpNGxiOBwgicQUySUGviesJCQe4ZA2JzkSCj6iaY fpGmMxA2y84lcLrrJqokQhepR/VcPmL7oTuo2mhfJR7ngjrhgI1MOQQsHwaaFDIhgrS8 qOBURQ7STPJHNNzkqe4KDQIsG/YdjrDdr1IoT/sHFHMFPlmSyVJFlJ9DoCFexE+k10SG 2lbK4fK5Fsr2kcAk7dfzeh3zAPCDPbg9ZshBnpWCigoI5MDUvTZ1CqN/lYj89LCln++M Lw== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2174.outbound.protection.outlook.com [104.47.56.174]) by mx0a-00273201.pphosted.com with ESMTP id 30s4jsx6hj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <6man@ietf.org>; Tue, 05 May 2020 17:51:16 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ltGzWhWMIse4aHBEQhTG587PNoGOW5JA7OJq+n3zdvPeNNqMD04o3LNgCAjjgrmhLje8cJRf5twqBHA2R7UmjB1kIEoamIo+den5XimjXrDRPruDtMFsHQczbE1q4xX+AJxfCihNoJW2qH2iH71RdkDFWJk9+HaIIp9VaaFht56cbVGlAIMi5KZ314oGzTY5A+ovQduF2waE7lgNX3wO4/DTUdoAFB2fgqC4/yukrdQakK/7TKUXvazYIEZKc7aW2pYSlt4RLzUVERm7cUjonP+yqjYw6ynkeCvzktSabq5jiyW/r/jmahc43NIQ7uWpPVg+X6eJFGml1UwZDxXfPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Uu54kOsJmpXUdNXY2J8tGgOIAHakyDk9m6qRJwZJv+s=; b=WBtXvsg3mfjjWwveW8FhAZsyUgAieIo63BN0410AiICW2p0TnfyBGwoFbXv7ytkeTWF9hkjI1DCmbV458P8sevMUqmULg9doo+ZdLVEAOoeB5LfA+jVkHfOhnj0lyUYZ71Ykvq9t+WdN8yi8Wyss1twRzHJNiXYV/KA6kZMc9h+ZVl263T344gaPeaSrFz1cpPlWGtHUPd1m+AB4cmdAZombfpgLZY+rVd8NIHNjFG1uf6w7zg+gwLYcmTLX24zVVUoh/HPDYf4GG+UKaUytGn1YMqg6yog335i9oXwczid8QtELR+JZXv+ZhCULhLCWFJ9hZiyDqruR990Id6/ZnQ== 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=Uu54kOsJmpXUdNXY2J8tGgOIAHakyDk9m6qRJwZJv+s=; b=frRrNPOqihZarQjyXGqu6F3JvBM+cNRjrMMxfMImHF9WJfpxA/SxqZdYhseHL9HqojpaBLNOhnlVYceWf+BbonOj/HdLDWOhzP8ZlM6ar+V2QF/i+nWFZ8TYLTX1FyH+4tpUEhZ7fBnyzVFhggzRniewBCUCStrMGae3vukLK9I= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB6060.namprd05.prod.outlook.com (2603:10b6:5:119::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.11; Wed, 6 May 2020 00:51:14 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.2979.025; Wed, 6 May 2020 00:51:14 +0000 From: Ron Bonica To: 6man <6man@ietf.org> Subject: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AdYjQANZ0MrEgFbBRG+Eev5I1WHYlQ== Date: Wed, 6 May 2020 00:51:14 +0000 Message-ID: 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_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-05-06T00:51:04.3795729Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=79c7e0ed-20d8-4ca5-90be-ed7319bdc0c4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b450b699-52f2-4dc4-dfa2-08d7f157941b x-ms-traffictypediagnostic: DM6PR05MB6060: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Tkba2bDfZH3VtPqqcK5ZK/3YSsJEDen4XOJyAQWKdQBiGAUdarUzb4uYg7DJKdCwrqG4XPBeaGNoDwgw+JKDD0OCsbCfuZWY4nVQ89a4SmLBDLryu8tWRjmxwjBOsUK91Y4F0bRS6vjZjxCoBzcYeytzCYkPg9Y0wcWD+RUQPdOXhgR8BWzm6Wbcd4A/gmLtak5986YVMOjWis3yEqicw3Y3mDALGeEuU1vbc7L5HxAxjt+nDzqdmgP5Jb05hwuiOjpYJODRf9ugt5V5lUJGPcTneoLbBXzIeaeGElS1+a7hpEwL+2m5hZHb8rdhNn55UV6z3MLH+tID2xDxHod49LQ7ubNP8Vve7UVlbz6r5DG3kcPq7FqOOsoVBDvk5YM5LxAIFHizOS2bkBmenc1xzh4z0XO0WJFq5p6E0F06JRabLaO1gFDA1Zwf06PjW0iIomwJTcShivtiTWxIhptvOK5ltpwtwovszQABamU+6JiAV1SxPSxaKctGud4JMXFQkrr6gWeIk4g0VKaW8F7JDA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(396003)(346002)(136003)(39860400002)(33430700001)(66946007)(478600001)(52536014)(316002)(2906002)(4744005)(71200400001)(33656002)(6506007)(7116003)(86362001)(33440700001)(66446008)(7696005)(186003)(26005)(5660300002)(8676002)(6916009)(66556008)(8936002)(64756008)(66476007)(55016002)(3480700007)(9686003)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: M9tpc+jd1DOEEdnNNw84v8QKUFgzLV8187NvWAXLy8uUH/gj4pKds+UPvCmGf616Sa0s6EBz03h/ZCkl09oNRI63T+BtHUwZ8Fdq7CxKh4jJwP7h3mwQ0qAKunq9osybZ4k46rXU+5FtUEueexfsdNO2yppgsp7QjMdYrxnbnH+qsch3vczdnISI/066C/KU3JdPaEC/HaN1Z9K/LcrmC4Rg03Ta4tSBYaudcdPSLA3LUmObmbeaU/343NQROaCdZduaMYozLd53L1uucwWi3t/j+Vxpvkiiw1Xg9VJQsvFXkTtm7tT7o84eGAgMeuF6Yun7906ZpTGw38ooTKt3u+ZgF55AqWi1zQPZK473zDvoRnLtjRUd1R5RAhJWshmYEFpZXFTUOorRly/PAeAC7eQclx+2d8HVrhK7vhi5J8clqtsMb6dy9zpl6EJ84Yiee5OSxFDLSH+YHjkC8fFHpRLw++V9s7yszpm1ZhmGDt62SQKceZTZH2ijmTsb/r/fPUK2ZZ2MiArzG1TTSCaP2VluEKqienIQJpVavu0BGnHTaFYElhqT/hAUIx1jC39BuNZoCYGYHRaQis5m/qSF0oF5Ze10gH36eigft7+ohbhpdk3P05VRizy04xlndUnBvVhPNoIBm6fqRB6MhcmTNNf26zcaeDZ5ioXvHDDj1nZle9cQx1AEQXaSnT/R1S5J8ALGSncjgDMeWawkul7Mm/GckDA9FOhnVJexvOfQ2XfEg2KnF5pGVFaxP4+Qx3Rhun6+fAvgFpDGWjQgtUzw5oFw3Pf6eFuNodLof2PekRw= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB6348C11B27DE657CBE81E223AEA40DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: b450b699-52f2-4dc4-dfa2-08d7f157941b X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 00:51:14.3689 (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: tp8bx3ctk07tmGoYp+qax0z061dGkg5e9hZqzRd2bpbmxXTz16FQyja5l2pCJaNpAz67GyiJ5iDxFLtbZ2lwlA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB6060 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-05-05_11:2020-05-04, 2020-05-05 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 clxscore=1031 mlxscore=0 bulkscore=0 mlxlogscore=799 priorityscore=1501 spamscore=0 adultscore=0 phishscore=0 impostorscore=0 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005060002 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 00:51:20 -0000 --_000_DM6PR05MB6348C11B27DE657CBE81E223AEA40DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, My apologies to Zafar Ali. Reading through the EANTC report, it appears the= Juniper demonstration SRv6 Routing Header insertion to support TI-LFA. In = that respect, Zafar is correct. However, we should not jump to the conclusion that such behavior is desirab= le. Ron Juniper Business Use Only Juniper Business Use Only --_000_DM6PR05MB6348C11B27DE657CBE81E223AEA40DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

My apologies to Zafar Ali. Reading through the EANTC= report, it appears the Juniper demonstration SRv6 Routing Header insertion= to support TI-LFA. In that respect, Zafar is correct.

 

However, we should not jump to the conclusion that s= uch behavior is desirable.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            Ron

 


Juniper Business= Use Only


Juniper Business Use Only

--_000_DM6PR05MB6348C11B27DE657CBE81E223AEA40DM6PR05MB6348namp_-- From nobody Tue May 5 18:12:21 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2811D3A0CA9 for ; Tue, 5 May 2020 18:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82yNYw8Es2cj for ; Tue, 5 May 2020 18:12:17 -0700 (PDT) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 CF53C3A0CA7 for <6man@ietf.org>; Tue, 5 May 2020 18:12:16 -0700 (PDT) Received: by mail-wr1-f44.google.com with SMTP id j5so179277wrq.2 for <6man@ietf.org>; Tue, 05 May 2020 18:12:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OtV+UY4C7A4EefR7G2wp4YVAv1fHR7WR0m0J/pi7oPg=; b=gkJQjtIjP2NXcBWL3MpWcep/Rv1EpVqISHYZASqOG+4TCNeBF4Zl5sCplc2vVNAIDb U6FX8Hf3Dn4atMhnLJYO2RUobPT+MYMJdGT/fDKiIvJwU5vOqjfqz3swREk2vjMOzHhz 6SpdKBIuQDvFnY1J9of9GXBCzvCnMRhtYZTjuTWYS4obSXIsGOeA1TUh8WjiaN2nj6B5 1V4ztROCJxugwoA996GExa3ZNB1O8+IQBeMqFFOB3zUX0toM/MVXqKTzOQwTvnRJ/3G4 tgnROL6v4RlRJ6c5CH2XBZ6zGocffLAPtluCT4o1TLldDP75Rd2hUqvmo3QOSOb+wfwj Z8IA== X-Gm-Message-State: AGi0PuZXJYOYUoz47azWsRF9gn7X9XPeAmrpUSTZcfCcFuWvWSZxdLAI pROsggBrpuLdkJoAIph0CRHtDqfQosIdberxtU9zkAus X-Google-Smtp-Source: APiQypIoPBrteQso6xa0Abp5aU37KRaiuhDinpTeqYcZjLoETNZMv9A+v3sORYSwCr0WJ3CL6s7KW3qfW0HK2a4irJE= X-Received: by 2002:a5d:414f:: with SMTP id c15mr6523852wrq.61.1588727534890; Tue, 05 May 2020 18:12:14 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 5 May 2020 18:12:03 -0700 Message-ID: Subject: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: 6MAN <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 01:12:19 -0000 I'd like to clarify a few things about draft-bonica-6man-ext-hdr-update-03 based on the comments made in today's interim meeting. I speak only for myself as a coauthor of the draft, of course, but I believe I'm generally on the same page as Ron for these points. First off, the purpose of this draft is NOT to prevent future "innovations" on using extension headers (especially in terms of insertions and deletions) forever. Protocols evolve over time, and RFCs have been and will be continuously updated or obsoleted with new requirements, changes in assumptions, or "innovations". Even if this draft intended to prevent such changes it wouldn't be impossible in practice. I thought that's too obvious to mention, but if we really worry about this draft to act as an "innovation blocker", we could add the obvious note. Secondly, in a sense this draft indeed clarifies an "obvious" point: "the node identified in the Destination Address field of the IPv6 header" in Section 4 of RFC8200 means the ultimate destination, not an intermediate node specified in a routing header, regarding "not [...] inserted, or deleted by any node". It was actually obvious to me and so it's unfortunate that we have to clarify such a point. But the recent discussion on draft-ietf-spring-srv6-network-programming proves that it's not obvious for some others and can even be used as a reason to pass a WGLC (and, in fact, I surprisingly realized that the RFC text could literally read in a different way). So I believe we need an explicit clarification. Third, several people suggested we should rather focus on conditions where we can loosen the restrictions. That effort is certainly highly appreciated and I'll support that, but I'd say that's a different topic than this draft, nor can it substitute for this draft. RFC 8200 specified the most generic principle and behavior of the IPv6 protocol. If we leave the ambiguity (I'd rather say a "bug") in the general protocol, we'll also leave it open for future protocols to casually violate the intent without giving considerations on the conditions that allow the exception. So IMO we need both: fixing the "bug" of the general case, and work on detailing the conditions to allow exceptions. I don't expect everyone agrees on all of my points, but at least I hope it helps understand the motivation of the draft more accurately. -- JINMEI, Tatuya From nobody Tue May 5 19:46:13 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CFE3A0D00 for ; Tue, 5 May 2020 19:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 JfbWzUPBNnzu for ; Tue, 5 May 2020 19:46:10 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 F327E3A0CFE for <6man@ietf.org>; Tue, 5 May 2020 19:46:09 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id g19so211883otk.5 for <6man@ietf.org>; Tue, 05 May 2020 19:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9vqLb3E7ldVarbRRVcHEe83LFnBPi1gIO6vSORmV1+E=; b=L+Xs7cQSXbNqxoeDBxAHGhmCp9JzrGuyJkYH3fU7Lpl0HMrEB5auVhXbfxOsabIZ1j 0HnWPcThB7+lV4subITK2sdEYw4l2fyYQ58NXFCXxq3W23RE2LdFI19Dta8QDj3cSq8J TSqA4+g33rW4LgZe1w0XwJoo5i9P9Tl75wdgTTKZHjtu1GiiPtSTNLp8IXMbYeoz+l+e /U1y3L+8SEVOCaKci63o1Gvot4OtTinuXa+B/Z4tUe/3AAwnzpybnA122Q+BeW3PN19h USixxj5XXmxpxVII+9Tohelqf8w7r/R4bvG+Yf8S8TbGbE7FgG9138EF+Gv8SlM3ATpY VbGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9vqLb3E7ldVarbRRVcHEe83LFnBPi1gIO6vSORmV1+E=; b=nLauSvGvsnPIAv5jvxcH13dLzr+m2IAb1TKWusQi0eA7StKRi6RUtUcDfB/u4qOsBX iuPe6HJRpMbPdnAWntjGboGTiRBF7oUUBcGz8AYJ8kJIGFZXtma55Biaun5yk9ygkGW2 fh05QYYEDemdwzNft9/9iP1yKnUIQiZkjQZQrRZHblKXKC5NRbdG617NQivtFEdQThpn kFP5PoKZv6JC7S3MnjSQ3zl9P3gv/XNr9pfJ2i7s76yI0WNdEmPE9WaoMFffVn7Ad3H8 nTCA5D2RnKgCBtxWCfeKM94jPmyk9fQTT14micjDvtXhbMRKPpZeXnKir/BgKN57TFIl QMgw== X-Gm-Message-State: AGi0PuaDXFAqG8qNFG0B/KeaRxpiI9H+yf/nBCn0yJaXPE2hEPtoQY3O ydtH13JMP0JqItixp3eNqJRLyovuRWs44OcYc3qKGQ== X-Google-Smtp-Source: APiQypK7qPSUwLgso7j4yAjf5RD6CAVWn1Xpz/6y8K9plsZ+1aSQ+v5LW5KAnWok4EtEHT7RZjHdgNXM9CC+JLd3/Lw= X-Received: by 2002:a05:6830:20d8:: with SMTP id z24mr5157819otq.74.1588733169050; Tue, 05 May 2020 19:46:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Wed, 6 May 2020 12:45:43 +1000 Message-ID: Subject: Re: Routing Header Insertion To: Ron Bonica Cc: 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 02:46:12 -0000 On Wed, 6 May 2020 at 10:51, Ron Bonica wrote: > > Folks, > > > > My apologies to Zafar Ali. Reading through the EANTC report, it appears the Juniper demonstration SRv6 Routing Header insertion to support TI-LFA. In that respect, Zafar is correct. > > > > However, we should not jump to the conclusion that such behavior is desirable. > > "Just because you can do something doesn't mean you should." > > Ron > > > > > Juniper Business Use Only > > > Juniper Business Use Only > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue May 5 19:52:55 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041983A0D03 for ; Tue, 5 May 2020 19:52:53 -0700 (PDT) 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, FREEMAIL_FROM=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 FXINylUQF4n1 for ; Tue, 5 May 2020 19:52:50 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 63DFE3A0D01 for <6man@ietf.org>; Tue, 5 May 2020 19:52:50 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id t9so174417pjw.0 for <6man@ietf.org>; Tue, 05 May 2020 19:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=V9Mc2uwP7GZFluxQvTnoQzKLJR4Xx5m2L54M7Czqlzw=; b=Dt8idTWiq5CQe8UGntZkAt2EPnEKYVkAXAtCbZcz4SEgc0RryJVGmP66xjMEdH/UMW kono+Gts82Bu1dWdx63dBcng/+8IA58X1kWpGfZt4W6EIDmBEAhrq8Jiys8hWq2/GEId fJ1xTs7TiS0paWRXbsuePc2QAZ341MlKXfBmnr8eDb5So5T9KQlMDbC8284vUbuJABkm gGGDsmy6/0rv9ohUPF0oY9j92CNtokx3KKE4ZSfuX58f08vL5DiEHJSEWHrEMfQoxQef eV9YsfraWWIgY5iaNwHyRamzdO3Bt4CO6oi8luRJavNyDAFx0apFo/PRstpsUT5DldDk h8EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V9Mc2uwP7GZFluxQvTnoQzKLJR4Xx5m2L54M7Czqlzw=; b=H+0ucgRXrwyAmnwxtGL5U6sR1ucm1YcRJ6ES/mQfwXOgbGoFeltjrtPy68W581Xun5 T7lyUB1/DKUk/t0gdsjCrU/K3Yv9kChoWFIU7bB+fPdZ0xcEEFLzxMC24Wa3tB1aPD3D 6g79NCLLQI+khXvnq2/wl+raYWFUTr0IVbAVNpkyMsCrapmtwDEFgmSH6+yUUn7YID1U 6Ag7SQJSc5sy9WQJmrltlwBWsvDGPpFKUC/DZ7Yj+uWbW5RFG+I/xYbepdfPWWODcL+h 7bE003OqIZZ3+OnFTMnlm3qC+idk8+qQqBKgAIR5f7x5alQa/ygT/a8Abfs0ms6uMAY7 lO5w== X-Gm-Message-State: AGi0PuZyMDFp46ivJAkimqYpGGUfV0G/+bqyvaFbD9qv/oPX+VwQq2VF t0Naee2TE4bphtZBW3DwJv0RBmEK/ww= X-Google-Smtp-Source: APiQypK28+dnJivkiESUrYq2lnWt+ooxR2fbfTIBocYRAh84ph7moM61jUrUCbOaDaBTiTd6AN8erA== X-Received: by 2002:a17:90b:246:: with SMTP id fz6mr6941173pjb.138.1588733569558; Tue, 05 May 2020 19:52:49 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.84]) by smtp.gmail.com with ESMTPSA id y2sm235567pfq.16.2020.05.05.19.52.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2020 19:52:48 -0700 (PDT) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , 6MAN <6man@ietf.org> References: From: Brian E Carpenter Message-ID: <9865489e-ad29-5eb0-0dd8-370812d92b12@gmail.com> Date: Wed, 6 May 2020 14:52:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 02:52:54 -0000 Due to the real world intervening, I had to drop off the meeting before this came up. So I appreciate this clarification. =20 > Secondly, in a sense this draft indeed clarifies an "obvious" point: > "the node identified in the Destination Address field of the IPv6 > header" in Section 4 of RFC8200 means the ultimate destination, not an > intermediate node specified in a routing header, ... I do agree that this was my interpretation at the time, but as I already mentioned we completely forgot to consider the case of routing headers (also forgotten in RFC7045), so it is understandable that some readers made a different interpretation. If we clarify this with a MUST NOT strength, what does that mean? It means (IMHO) that a specification which allows the MUST NOT to be ignored needs to say so explicitly, and needs to explain why it's safe. Since all IETF standards are voluntary standards, it's hard to argue that is unthinkable. (If it gets IETF rough consensus at Last Call, of course.) Regards Brian On 06-May-20 13:12, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > I'd like to clarify a few things about > draft-bonica-6man-ext-hdr-update-03 based on the comments made in > today's interim meeting. I speak only for myself as a coauthor of the > draft, of course, but I believe I'm generally on the same page as Ron > for these points. >=20 > First off, the purpose of this draft is NOT to prevent future > "innovations" on using extension headers (especially in terms > of insertions and deletions) forever. Protocols evolve over time, and > RFCs have been and will be continuously updated or obsoleted with new > requirements, changes in assumptions, or "innovations". Even if this > draft intended to prevent such changes it wouldn't be impossible in > practice. I thought that's too obvious to mention, but if we really > worry about this draft to act as an "innovation blocker", we could add > the obvious note. >=20 > Secondly, in a sense this draft indeed clarifies an "obvious" point: > "the node identified in the Destination Address field of the IPv6 > header" in Section 4 of RFC8200 means the ultimate destination, not an > intermediate node specified in a routing header, regarding "not [...] > inserted, or deleted by any node". It was actually obvious to me and > so it's unfortunate that we have to clarify such a point. But the > recent discussion on draft-ietf-spring-srv6-network-programming proves > that it's not obvious for some others and can even be used as a reason > to pass a WGLC (and, in fact, I surprisingly realized that the RFC text= > could literally read in a different way). So I believe we need an > explicit clarification. >=20 > Third, several people suggested we should rather focus on conditions > where we can loosen the restrictions. That effort is certainly highly > appreciated and I'll support that, but I'd say that's a different > topic than this draft, nor can it substitute for this draft. RFC 8200 > specified the most generic principle and behavior of the IPv6 > protocol. If we leave the ambiguity (I'd rather say a "bug") in the > general protocol, we'll also leave it open for future protocols to > casually violate the intent without giving considerations on the > conditions that allow the exception. So IMO we need both: fixing the > "bug" of the general case, and work on detailing the conditions to > allow exceptions. >=20 > I don't expect everyone agrees on all of my points, but at least I > hope it helps understand the motivation of the draft more accurately. >=20 > -- > JINMEI, Tatuya >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue May 5 20:55:35 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD693A0D22 for ; Tue, 5 May 2020 20:55:34 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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, 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=uHzowyhC; dkim=pass (1024-bit key) header.d=juniper.net header.b=SqrcASsC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBxt3vEtw6it for ; Tue, 5 May 2020 20:55:31 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7913A0C17 for <6man@ietf.org>; Tue, 5 May 2020 20:55:31 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0463tM3W009913; Tue, 5 May 2020 20:55:30 -0700 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=dCiKmnGTA1QN5Lf57AGGtDHEpDfSEtg846QFwO9n+j8=; b=uHzowyhCG1P3K/1Z6ED0KpTWwPcDcH7FPzpQpyLvf7F5FOhYua2yBQBUjN8hFPLB5+Vi OlMLUSs5csHSIO8cARs5r9K1A1a/VcFYYjRLxku1Db/uisNqKZBdkJLQXqQZDq/EHvPQ S28xn3DQETbuDmtwanytqZfvrI7ENSYtWXBF/0k66KVBTgnBQfNZeRlgETTSTCVFqLlH uJKTOzHKiTOoiUqV2SVPg5xLrS9kAxS50V5hjpNAKOG5GBPy/FaYon3fPy0ORnQxVQeD 4/oBIh4Qf1m9Bo42xwvuIMAq1IKAZN4IKnug3z6ETmVw9fZ/K4QdFeSE7lEmYoGmbKRG pg== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2176.outbound.protection.outlook.com [104.47.57.176]) by mx0a-00273201.pphosted.com with ESMTP id 30s6tyeas9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 May 2020 20:55:29 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cPtDaU32N5x1SKaa6M9Z94KhVDVb3kjVLBYLmWTkZZzuHRG8UWHI20JpxiNFtrtTXhGBHAJY6voFR/sdeLFmlxfYX8SDgUWtRO2d17fXWZnIpkRvXM1YXGkSYEFBFjxE/tLsuhzZAz/NywGfsEBuZBIZ78HYP+glEQ2i3clYkjdylHk0cT8QrObJ8wmYxMksxl4LBm6yCz7IZfl64IW1JcoW2S40W2BAT4Ia98A58SYdGHBoY5ahcP/Q4LqSvZuzwTU4JDIRbsePdRWjLQ5441ts8zbYz/QaDCDLMatfY1Homca0TR0Hr8xgZzqPHXvg1QVOgfsYM8voLnlvezxkxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dCiKmnGTA1QN5Lf57AGGtDHEpDfSEtg846QFwO9n+j8=; b=DzYUOTWy6sQ74rBFmm6q5NVKdTdoxb9Pf9ne55xd8m+ITWH/YYy4C56EEVAB8GKqr5scHvticIFEX8FWvsFV89541obCQ3LdwE6FDzMl3few0dk6cYNCEYEAgNlVugMWZGQ1pZANausqpNBn0xN8gXEq0qqVLhzTM8a/XgovyuJql+H2R1mUUxOant63xMpz0ZmLcHGZbKGD2ZPjLYieysU9aheHXrdUIM20jzR0Mg/UWuK6Tn5j4pzdG7DcyXhNFSnHDplxCRyXv4+ZgupO5oTgX/m/1m5UmiRX2hUhLyvfkMIfz4FV5QxdbPiqsifcQ+Fhixuea5iEPR7Rf5Zb8A== 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=dCiKmnGTA1QN5Lf57AGGtDHEpDfSEtg846QFwO9n+j8=; b=SqrcASsCebxEaB75zhW1DvLU1SqK03R/u0ffOE+Jg0YzYaMR4g11Q0lyLaYaL07HppxsmBrbyMXqLTk8SMy2IP4rFNHu4EcP6x3ho7CbRg+UsXLZ2tn6OkBvXQMKCgK0GpyvzB9JCAYqrwbyTrGKIeDrKdgTu2fZyuCAzqx+Xhg= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB6138.namprd05.prod.outlook.com (2603:10b6:5:3a::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.11; Wed, 6 May 2020 03:55:28 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.2979.025; Wed, 6 May 2020 03:55:27 +0000 From: Ron Bonica To: 6man <6man@ietf.org>, "Eric Vyncke (evyncke)" Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-15.txt Thread-Topic: New Version Notification for draft-bonica-6man-comp-rtg-hdr-15.txt Thread-Index: AQHWI1fYULA9uWsYoUWYl/jF2yHGK6iaafWA Date: Wed, 6 May 2020 03:55:27 +0000 Message-ID: References: <158873632075.16057.9567525301158191750@ietfa.amsl.com> In-Reply-To: <158873632075.16057.9567525301158191750@ietfa.amsl.com> 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_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-05-06T03:55:26.5080690Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=f7d6a596-ab1b-4e39-b8af-03c675bcef87; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3d1f2280-c4f1-4f01-ce88-08d7f1715070 x-ms-traffictypediagnostic: DM6PR05MB6138: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HURJXpOUOBIjtpeVCsLVNaWSQUmmOYZ54SsSpCcyj2SkgLNS2DN0LESt4QyyPbWoKISm2j7khzrQqVP6ElejsAc5HNe9gyAOlfEAcr+kNHtI7EBpY4bTgI5H4Vif4rlW5Rt0F7WzUDROh4q56MACqc5peRqSrxLmYZo7SyjsDRF4hXOTxvr/uGz2APGAPWswCLLKfElf4I8ZNRyMytEq6aaMSibNyqx+byJ/1F5cw2+m+QNprYOzvbADoDv0Uzs2TuRbUflxnfTdoqj2JJUu+gRzs2DeufweyTIECjksgEJtTLrdnlANHdFwaQa/AKoqVGxi/vSGisKYEvT8qoUd7ehmOeOLlGvc0QemHqfC6UuPJm52hDs7MiB+6l3wC0gT5mjRRveSA7eZLeD69Vyr+UC5IY/w/3iPKX0OpKDWx73bneZSYI55IYPIsphB0Y5R1+Fi2Cc3JKqC4I6pnw0CrdsmxTcE/GwR1XMocWzRgSoEcNKR6UyAIfwtTSHjdUAz0eK7dlt1nLU0WviKm4VSB1HgNWASBiKLoNlC0I1I9VUl7NkIeFUy0wZuxvaz/UT1kIfF7lweu574fMNJa+/ECK6OWNXNnUfr0wr030FMaIc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(136003)(396003)(346002)(366004)(33430700001)(66556008)(66476007)(66946007)(53546011)(9686003)(8676002)(6506007)(33656002)(316002)(186003)(5660300002)(26005)(66574014)(33440700001)(8936002)(7696005)(76116006)(55016002)(15650500001)(110136005)(966005)(52536014)(478600001)(64756008)(66446008)(71200400001)(86362001)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: X8Tf82YTq7HZzQ6sMDC19RCi4sWXl1ES2bXdMtQnyimPvh/iEB5eolcRZMbrV3HzRNpDcVsmhoLLr7EqXOj+WsvTWAUcI4Yc7PGl0yawvEDxf3p88yFlTNv1j5bpQZoXh7ZTlAJc1qYtoPbIUEijYdwIUS//tSBerU+U7VCojU1NGtCRbiDNGujZ9R3UK/oe1iOcjX1+3osbDk2m52s+OUYcGyS+TrW881VdhCvdycmWoHu9pTs66QkL1X2vm8xovX977n949dpIHeWEXgx8Fc2ZCZVxCwLqHasr1MaebkrtiE2F8m+J4LYiPNau94yOUhsAOWDcfut9zHVV/EuVGwIrAngV9BjHXRxKfQqxykKfUhZ76+hE49iN+eJS71ppnaY3cPTW5dceKEmRCnOpwiXYvyJYgikIk9NiWZDSHcYGsMsjEG745wzpt0I6hHV39TMaqjGSFlDNSqwN5YyJ6TtqYOh6jXwTqChdpbnGexpTQaJ9ZoInSCFy+vfAkVtwHe+I99RU3UIGfmdRyPRoFeoYx2Z0/QISSfp5YVrz3BfYTbZGEWYWh52BN5LvA99fBybvzHZpxK3tklNiEzcItAEKWMHMLgC5PDKxnayWCi+lllXRq/IZEhgOJ8rlf9Li2HgrL9ilNd4bBQSFOnxeN1RfydkmbEPFWC87MaQUwzES2nZbnipwo/SHxDM1KytEVCVif+be5igxnMaQ44TFI0etQYaF3U+g6Ymb/1T27n4t8vraw8qej1H/VNIJraHPtxTJ4mBzn0uH7EViKtpOsf2589jGLgz1IfWJ6s8zEgE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 3d1f2280-c4f1-4f01-ce88-08d7f1715070 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 03:55:27.8863 (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: Zgnn02p6BBo+uYhSaaCy1FkDPKRbdllnq2poiLZS81z/t4aPGMTUBOFPJYFYBYGr11YFJ0ASEVjO/iVJXlzyNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB6138 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-05-06_01:2020-05-04, 2020-05-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 mlxscore=0 phishscore=0 clxscore=1011 priorityscore=1501 bulkscore=0 impostorscore=0 malwarescore=0 suspectscore=0 spamscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005060028 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 03:55:34 -0000 Rm9sa3MsDQoNCkF0IHRoZSBsYXN0IHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nLCBFcmlrIFZ5bmNr ZSBtYWRlIHRoZSBmb2xsb3dpbmcgc3VnZ2VzdGlvbnMgcmVnYXJkaW5nIHRoZSBDUkggZHJhZnQ6 DQoNCi0gUmVtb3ZlIHRoZSBTZWN0aW9uIGNvdmVyaW5nIElDTVAgQ29uc2lkZXJhdGlvbnMsIGJl Y2F1c2UgZXZlcnl0aGluZyB0aGF0IGl0IHNheXMgaXMgYWxyZWFkeSBjb3ZlcmVkIGJ5IFJGQyA0 NDQzDQotIEluIFNlY3Rpb24gNSwgcmVtb3ZlIHRoZSBwcm9jZXNzaW5nIHJ1bGUgdGhhdCBmb3Ji aWRzIGZvcndhcmRpbmcgb2YgcGFja2V0cyB3aXRoIG11bHRpY2FzdCBzb3VyY2UgYWRkcmVzc2Vz LCBiZWNhdXNlIFJGQyA4MjAwIGFscmVhZHkgZm9yYmlkcyB0aGlzLg0KLSBJbiBTZWN0aW9uIDUs IHJlbW92ZSB0aGUgcHJvY2Vzc2luZyBydWxlIHRoYXQgZm9yYmlkcyBmb3J3YXJkaW5nIG9mIHBh Y2tldHMgd2l0aCBsaW5rLWxvY2FsIHNvdXJjZSBvciBkZXN0aW5hdGlvbiBhZGRyZXNzZXMsIGJl Y2F1c2UgUkZDIDgyMDAgYWxyZWFkeSBmb3JiaWRzIHRoaXMuDQoNCkVyaWssDQoNClBsZWFzZSBs b29rIGF0IHRoZSBkaWZmIGZpbGUgdG8gc2VlIGlmIEkgY2F1Z2h0IGFsbCBvZiB0aGUgcnVsZXMg dGhhdCB5b3Ugd2FudGVkIHRvIGRlbGV0ZS4NCg0KQWxsLA0KDQpJIGRvbid0IHJlbWVtYmVyIGFu eSBvdGhlciBhY3Rpb25hYmxlIHN1Z2dlc3Rpb25zIG9uIHRoaXMgZHJhZnQuIElmIHlvdSBoYWQg b25lLCBwbGVhc2UgcmVtaW5kIG1lIHdoYXQgaXQgd2FzLg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUm9uDQoNCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+IFNlbnQ6IFR1ZXNkYXksIE1heSA1LCAyMDIw IDExOjM5IFBNDQo+IFRvOiBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbQ0KPiA8 QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT47IFJvbiBCb25pY2EgPHJib25pY2FAanVu aXBlci5uZXQ+Ow0KPiBUb21vbm9idSBOaXdhIDx0by1uaXdhQGtkZGkuY29tPjsgTHVheSBKYWxp bA0KPiA8bHVheS5qYWxpbEBvbmUudmVyaXpvbi5jb20+OyBZdWppIEthbWl0ZSA8eS5rYW1pdGVA bnR0LmNvbT47IEVYVC0NCj4gQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSA8QW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1ib25pY2EtNm1hbi1jb21wLXJ0Zy1oZHItDQo+IDE1LnR4dA0KPg0K PiBbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQo+DQo+DQo+IEEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ib25pY2EtNm1hbi1jb21wLXJ0Zy1oZHItMTUudHh0DQo+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9uIEJvbmljYSBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGDQo+IHJlcG9zaXRvcnkuDQo+DQo+IE5hbWU6ICAgICAgICAgICBkcmFmdC1i b25pY2EtNm1hbi1jb21wLXJ0Zy1oZHINCj4gUmV2aXNpb246ICAgICAgIDE1DQo+IFRpdGxlOiAg ICAgICAgICBUaGUgSVB2NiBDb21wcmVzc2VkIFJvdXRpbmcgSGVhZGVyIChDUkgpDQo+IERvY3Vt ZW50IGRhdGU6ICAyMDIwLTA1LTA1DQo+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCj4gUGFnZXM6ICAgICAgICAgIDE1DQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYm9uaWNhLTZtYW4tY29tcC1ydGctaGRy LTE1LnR4dA0KPiBTdGF0dXM6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWJvbmljYS02bWFuLWNvbXAtcnRnLWhkcg0KPiBIdG1saXplZDogICAgICAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvbmljYS02bWFuLWNvbXAtcnRnLWhkci0xNQ0K PiBIdG1saXplZDogICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LWJvbmljYS02bWFuLWNvbXAtcnRnLWhkcg0KPiBEaWZmOiAgICAgICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYm9uaWNhLTZtYW4tY29tcC1ydGctaGRyLTE1 DQo+DQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdHdvIG5ldyBSb3V0 aW5nIGhlYWRlciB0eXBlcy4gIENvbGxlY3RpdmVseSwNCj4gICAgdGhleSBhcmUgY2FsbGVkIHRo ZSBDb21wcmVzc2VkIFJvdXRpbmcgSGVhZGVycyAoQ1JIKS4gIEluZGl2aWR1YWxseSwNCj4gICAg dGhleSBhcmUgY2FsbGVkIENSSC0xNiBhbmQgQ1JILTMyLg0KPg0KPg0KPg0KPg0KPiBQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ DQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCg== From nobody Wed May 6 00:10:32 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FC23A079D for ; Wed, 6 May 2020 00:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JPT6gBdX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jQLv805P Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CC2g76VCvc28 for ; Wed, 6 May 2020 00:10:28 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2913A0798 for <6man@ietf.org>; Wed, 6 May 2020 00:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4520; q=dns/txt; s=iport; t=1588749028; x=1589958628; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2rWqfZGd1TTSr0w0INNj8+gL/RpSTM+oGROsjsY12uQ=; b=JPT6gBdX6IoOGKmaesdpMHrAtLz6k9jfH64C7yyWVnFSK2sY0iQvTiQb ULSL8aP58Af1XFeeuMBODT2aJOdRH7fko3ZFbkXRDDuUxcOzL9CBo3Img DM4fWhvcvACUIpRcFG+rawU0ST7rd5ID03r3GHjIDyxU+FT+4PNvJPaPm o=; X-IPAS-Result: =?us-ascii?q?A0BjCQAcYrJe/5JdJa1mHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UeBVFEFblgvKoQjg0YDizSCEZg1gUKBEANUCwEBAQwBASUIAgQBAYREAheBZ?= =?us-ascii?q?yQ4EwIDAQEBAwIDAQEBAQUBAQECAQUEbYVWDIVxAQEBAQMSEREMAQE1AwsEA?= =?us-ascii?q?gEIDgMDAQEBAwImAgICMBUICAIEARIigwQBgksDLgEOqFsCgTmIYXaBMoMAA?= =?us-ascii?q?QEFgTYCDkFCglMYgg4JgQ4qgmOJYRqBQT+BOByCTT6CZwEBAgEBGIEUARIBK?= =?us-ascii?q?DOCWDOCLZFJhj6aTgqCSIgYj34dgluBDIdVkWSQF4lUk0gCBAIEBQIOAQEFg?= =?us-ascii?q?WkiZnBwFRpLAYI+CUcYDZBCg3KFFIVCdAI1AgYBBwEBAwl8kUoBAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3Af0c2wBwNEzNDKKnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWPt/dwil7RUJ+d7f9Y2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkpIHsfmakeUpHCuvnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.73,358,1583193600"; d="scan'208";a="461888098" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2020 07:10:27 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 0467ARVY012779 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2020 07:10:27 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 02:10:26 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 03:10:25 -0400 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 6 May 2020 02:10:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HpkYdFAwLHBoMCd1xrOeJWG8BHp4muS9zOOeCKph8lF24+Y3mUwSfoEI1vUwN1sm1Co/XqMDs/WZk8k9gJq8F1PCjJALE+6jlA8YRDk1V2wb+n0pRLBkpiWy058Khq+ryOuI1xcc2+dHM8VAAyk/xym65GbPQzqYsncClLKWkMrjuiK+ztzjx8hNwla87YnMIIZsPXVJpsAtDR6wDvbPXXl16FY46Cz0xLYfYOGqNpl7uf9NR4oVIbyw4TjR3DmVggKP8el4TkXLcz7AoMfeNko3l0/Ab7ZgGwktLpL+z+9ssWCex/acSpswGmUCbMeQ+59TTEG2gxIMSVeZiTCnlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2rWqfZGd1TTSr0w0INNj8+gL/RpSTM+oGROsjsY12uQ=; b=gm1AMDBa9z/TSaThalHCfL+ye0+qhp+lUaMTb0DY4UVrI+tN55xQRi/GiIMJ3ozk82nqDmeGD/fc8Fo4wTD6Ml9sDGXnSkt23ByoQ7j03ubkoGvzpsyov2sz8avkWgftpivZ8eytiuOYNETZu7m8UpR+iMAoYDC6Mk0ZoyaBtRdQkzw/bTxxxph70ePzracD8FWKFUQBiJkd/JZqWHZlsetgChOV3qDQH4wNHK1rPCY7V2Mw2BSEVoYOutWs8i5pZS+Uo/26ff/y6WdkTebABOPAlHRedm8LZRCvy6/I0McrcJ4nKjw8XQ/iJ3eaxpqVgSvegoOkQAGi71oss11NeQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2rWqfZGd1TTSr0w0INNj8+gL/RpSTM+oGROsjsY12uQ=; b=jQLv805PncW9ePve8aOwgTcTsH4bRQhqVO9gDHGmTMOfeK5d7feBkkN/Q27CLjB7br6Bdo6n19I6FjismJPh3B/IsnRuhvP55LcV9CxTnr7d0/ICP8/pUqGuVfgwjuO3s1j0QtCbzdO3dD8Hv7mU2W0gHgaLH/bLjGx+b+0gLUA= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1450.namprd11.prod.outlook.com (2603:10b6:4:f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.21; Wed, 6 May 2020 07:10:23 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c%9]) with mapi id 15.20.2979.028; Wed, 6 May 2020 07:10:23 +0000 From: "Eric Vyncke (evyncke)" To: Ron Bonica , 6man <6man@ietf.org> Subject: Re: New Version Notification for draft-bonica-6man-comp-rtg-hdr-15.txt Thread-Topic: New Version Notification for draft-bonica-6man-comp-rtg-hdr-15.txt Thread-Index: AQHWI1fYULA9uWsYoUWYl/jF2yHGK6iaafWAgABbsYA= Date: Wed, 6 May 2020 07:10:23 +0000 Message-ID: References: <158873632075.16057.9567525301158191750@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:8c61:47ef:9ce5:3a3a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c8715dab-7cd5-4e31-6ce4-08d7f18c8b98 x-ms-traffictypediagnostic: DM5PR11MB1450: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: X35hgT20SGJwzqB4YWvMOiJU2kzuRqC0uMWbIIEr4mP9eHa+EOMzS8uPUDS3LEqxaao9EaUAmBVz4UaD1Lk+XfvJP6pWwEZ7iQGu15SfO9X/6oEDvluNXEuVPaS+qj4fqAL+ppbzbEGThmfkvaOEuVGJkNDJMId2tFCY00HtzN9ztzuD9FMLW7BKu6GXAx+S7TFgcKgbwsfCXYsIfSh79W3WxefrX36Dn3wPO2kvX9q5WRFpIiDb8UvsvNpJCVPWM21H9v2HHRmD7JafEEoErmyjsZi3D0C+TPvTRKTzMussGXxJvrMtzu221RFQ/Hzhh1NWxhRpShSXzHhwSpsSkO9uykRFwpbjABccGphbUz2JFYRU7SXTgWO/iDa+80P+3hNeVBj4tkFrNB2Xpwryh8W48AdYwSiF2iq9NhGoGz28DljDyVwph5P3azDzgAx5vuZMXF/bD5hSUL2gw21/qyJvLjRk5hvsw1jAsUpSVj1XZxC3rCu5P1C5Q1K8ntc2OvKyAVGVhSSIEGH2xAYCvgkyMaW2fuNUtiqZl87YJmByWXBWnf5yDjdtcPN5w0nmym9fexc4qiYQpZ9U1zklTAezQkXmR4GQR8dKhvmROVM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(396003)(376002)(39860400002)(366004)(33430700001)(71200400001)(76116006)(6486002)(64756008)(66556008)(8676002)(91956017)(53546011)(66476007)(2906002)(66446008)(66946007)(15650500001)(8936002)(6506007)(316002)(6512007)(33656002)(478600001)(36756003)(186003)(86362001)(110136005)(5660300002)(33440700001)(966005)(2616005)(66574014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: OitUROZGE4XR+N3rdIv2wHEh57vpbRCV95n6fYTSKwTMxtg2Hi3POCxZMimPCxpjKlMcpOBbLpgZwG9VnHeupsoHXNOXIcSqfzHsx/YrnnoUY3fNnjr9RfIF+I/f8VTfyC4hXMuhtB+Q6wNFY380OXvi9WNxUVyQWHmqioLQzTc0vcRj65w2KmxdYQMDwVnXLG81t4ftB4BanNU+2KY/6ANSUC2ffYwmhfTfSAoqq3mrhuk+Zw7YgZehTryKi7o01FLya5Bj7ZBNlo/Ogor984A8b8Y3hYU2I1ijS0p+0o63x9pvuWsKGmPE/3MXbdWJxj0AJ7aQMPzO4Ias+HQZLmgJo35leNQuxoqfmB97gj4PQvh1fXz077dqbHOK1go/Mi+2mJq+ajz4UcJ4LuQrFkzUogTr4yaX/dKZM++aSTmmd4Jo3UsYX1OJk0lSmGRrJWAceSmJyoqG2qi0EljRSaltSRK+es6iXlnMCA5X3TqEcRx8hbT3Maiir1Kk3INz+7/4Yo5Ygkuoktp/R+F/DLyNmPp1U7nvdEsh25W9kbGmcjnJg6ipppooe0Vy+ps4Ea7t+J2JIE6OrX71VWyvNukQjiNpayc/neCu4MXUKa7YNa+5USNlbRB2nI8C1mXBO8c6+itH0ufPMm6MQ1r0slTrE2L/YNVPpFTkvzu3uYRUJ6AIGCdEh9TdfqYyHjoUGu9xckNvo4ckUkWWZkrtOlSt72OO9oBetZ/FMfGFE4yXOMx69q1t7m21qCASMVU5STJr5/HhT3OliSkS+Mvp1YvJafEVYIWfe9DlL8jOZcYBOUEWjOOFgE5FcDABp87/17rZ8wUPCHsIJcjyMLq05B2v+7meTHHjY4x1DkjtPCM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <138FD7519A348944A808B1DA5D2FD2D8@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c8715dab-7cd5-4e31-6ce4-08d7f18c8b98 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 07:10:23.4053 (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: ACLFbLKkWy1q+MSdCsuuY+bEd84ZVx1nCcu3JkSSZtG+7RzRHtZFgVrXeskmGFBjToJfb5Z06u1a9Ixv/i2ysQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1450 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 07:10:30 -0000 Um9uDQoNClRoZSByZXZpc2VkIEktRCBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIEkgbWFkZSBkdXJp bmcgdGhlIGludGVyaW0gb2YgdGhlIDZ0aCBvZiBNYXkgMjAyMC4NCg0KUmVnYXJkcw0KDQotcsOp aWMNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvbiBCb25pY2EgPHJi b25pY2FAanVuaXBlci5uZXQ+DQpEYXRlOiBXZWRuZXNkYXksIDYgTWF5IDIwMjAgYXQgMDU6NTUN ClRvOiA2bWFuIDw2bWFuQGlldGYub3JnPiwgRXJpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29t Pg0KU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYm9uaWNh LTZtYW4tY29tcC1ydGctaGRyLTE1LnR4dA0KDQogICAgRm9sa3MsDQoNCiAgICBBdCB0aGUgbGFz dCB2aXJ0dWFsIGludGVyaW0gbWVldGluZywgRXJpayBWeW5ja2UgbWFkZSB0aGUgZm9sbG93aW5n IHN1Z2dlc3Rpb25zIHJlZ2FyZGluZyB0aGUgQ1JIIGRyYWZ0Og0KDQogICAgLSBSZW1vdmUgdGhl IFNlY3Rpb24gY292ZXJpbmcgSUNNUCBDb25zaWRlcmF0aW9ucywgYmVjYXVzZSBldmVyeXRoaW5n IHRoYXQgaXQgc2F5cyBpcyBhbHJlYWR5IGNvdmVyZWQgYnkgUkZDIDQ0NDMNCiAgICAtIEluIFNl Y3Rpb24gNSwgcmVtb3ZlIHRoZSBwcm9jZXNzaW5nIHJ1bGUgdGhhdCBmb3JiaWRzIGZvcndhcmRp bmcgb2YgcGFja2V0cyB3aXRoIG11bHRpY2FzdCBzb3VyY2UgYWRkcmVzc2VzLCBiZWNhdXNlIFJG QyA4MjAwIGFscmVhZHkgZm9yYmlkcyB0aGlzLg0KICAgIC0gSW4gU2VjdGlvbiA1LCByZW1vdmUg dGhlIHByb2Nlc3NpbmcgcnVsZSB0aGF0IGZvcmJpZHMgZm9yd2FyZGluZyBvZiBwYWNrZXRzIHdp dGggbGluay1sb2NhbCBzb3VyY2Ugb3IgZGVzdGluYXRpb24gYWRkcmVzc2VzLCBiZWNhdXNlIFJG QyA4MjAwIGFscmVhZHkgZm9yYmlkcyB0aGlzLg0KDQogICAgRXJpaywNCg0KICAgIFBsZWFzZSBs b29rIGF0IHRoZSBkaWZmIGZpbGUgdG8gc2VlIGlmIEkgY2F1Z2h0IGFsbCBvZiB0aGUgcnVsZXMg dGhhdCB5b3Ugd2FudGVkIHRvIGRlbGV0ZS4NCg0KICAgIEFsbCwNCg0KICAgIEkgZG9uJ3QgcmVt ZW1iZXIgYW55IG90aGVyIGFjdGlvbmFibGUgc3VnZ2VzdGlvbnMgb24gdGhpcyBkcmFmdC4gSWYg eW91IGhhZCBvbmUsIHBsZWFzZSByZW1pbmQgbWUgd2hhdCBpdCB3YXMuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KDQogICAgSnVuaXBlciBCdXNpbmVzcyBV c2UgT25seQ0KDQogICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQogICAg PiBTZW50OiBUdWVzZGF5LCBNYXkgNSwgMjAyMCAxMTozOSBQTQ0KICAgID4gVG86IEVYVC1BbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQogICAgPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0 ZWxlY29tLmNvbT47IFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+Ow0KICAgID4gVG9t b25vYnUgTml3YSA8dG8tbml3YUBrZGRpLmNvbT47IEx1YXkgSmFsaWwNCiAgICA+IDxsdWF5Lmph bGlsQG9uZS52ZXJpem9uLmNvbT47IFl1amkgS2FtaXRlIDx5LmthbWl0ZUBudHQuY29tPjsgRVhU LQ0KICAgID4gQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSA8QW5kcmV3LkFsc3RvbkBs aXF1aWR0ZWxlY29tLmNvbT4NCiAgICA+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtYm9uaWNhLTZtYW4tY29tcC1ydGctaGRyLQ0KICAgID4gMTUudHh0DQogICAg Pg0KICAgID4gW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KICAgID4N CiAgICA+DQogICAgPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9uaWNhLTZtYW4tY29t cC1ydGctaGRyLTE1LnR4dA0KICAgID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBSb24gQm9uaWNhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCiAgICA+IHJlcG9zaXRvcnkuDQog ICAgPg0KICAgID4gTmFtZTogICAgICAgICAgIGRyYWZ0LWJvbmljYS02bWFuLWNvbXAtcnRnLWhk cg0KICAgID4gUmV2aXNpb246ICAgICAgIDE1DQogICAgPiBUaXRsZTogICAgICAgICAgVGhlIElQ djYgQ29tcHJlc3NlZCBSb3V0aW5nIEhlYWRlciAoQ1JIKQ0KICAgID4gRG9jdW1lbnQgZGF0ZTog IDIwMjAtMDUtMDUNCiAgICA+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N CiAgICA+IFBhZ2VzOiAgICAgICAgICAxNQ0KICAgID4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ib25pY2EtNm1hbi1jb21wLXJ0Zy1o ZHItMTUudHh0DQogICAgPiBTdGF0dXM6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWJvbmljYS02bWFuLWNvbXAtcnRnLWhkcg0KICAgID4gSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib25pY2EtNm1hbi1jb21wLXJ0 Zy1oZHItMTUNCiAgICA+IEh0bWxpemVkOiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtYm9uaWNhLTZtYW4tY29tcC1ydGctaGRyDQogICAgPiBEaWZmOiAgICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYm9uaWNhLTZt YW4tY29tcC1ydGctaGRyLTE1DQogICAgPg0KICAgID4gQWJzdHJhY3Q6DQogICAgPiAgICBUaGlz IGRvY3VtZW50IGRlZmluZXMgdHdvIG5ldyBSb3V0aW5nIGhlYWRlciB0eXBlcy4gIENvbGxlY3Rp dmVseSwNCiAgICA+ICAgIHRoZXkgYXJlIGNhbGxlZCB0aGUgQ29tcHJlc3NlZCBSb3V0aW5nIEhl YWRlcnMgKENSSCkuICBJbmRpdmlkdWFsbHksDQogICAgPiAgICB0aGV5IGFyZSBjYWxsZWQgQ1JI LTE2IGFuZCBDUkgtMzIuDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KICAgID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICA+DQogICAgPiBUaGUgSUVURiBT ZWNyZXRhcmlhdA0KICAgID4NCg0KICAgIEp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCg0K From nobody Wed May 6 02:33:18 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6593A064F for ; Wed, 6 May 2020 02:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 l9QAhaMlYX1u for ; Wed, 6 May 2020 02:33:14 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA1E3A064A for <6man@ietf.org>; Wed, 6 May 2020 02:33:13 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:5d77:87f8:10e6:7f2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id A757E4E11C5D; Wed, 6 May 2020 09:33:12 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id EB0BB3377319; Wed, 6 May 2020 11:33:10 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 From: otroan@employees.org In-Reply-To: <9865489e-ad29-5eb0-0dd8-370812d92b12@gmail.com> Date: Wed, 6 May 2020 11:33:10 +0200 Cc: =?utf-8?B?56We5piO6YGU5ZOJ?= , 6MAN <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <9865489e-ad29-5eb0-0dd8-370812d92b12@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 09:33:16 -0000 > On 6 May 2020, at 04:52, Brian E Carpenter = wrote: >=20 > Due to the real world intervening, I had to drop off the meeting = before > this came up. So I appreciate this clarification. >=20 >> Secondly, in a sense this draft indeed clarifies an "obvious" point: >> "the node identified in the Destination Address field of the IPv6 >> header" in Section 4 of RFC8200 means the ultimate destination, not = an >> intermediate node specified in a routing header, ... >=20 > I do agree that this was my interpretation at the time, but as I = already > mentioned we completely forgot to consider the case of routing headers > (also forgotten in RFC7045), so it is understandable that some readers > made a different interpretation. >=20 > If we clarify this with a MUST NOT strength, what does that mean? > It means (IMHO) that a specification which allows the MUST NOT to be > ignored needs to say so explicitly, and needs to explain why it's = safe. > Since all IETF standards are voluntary standards, it's hard to argue > that is unthinkable. (If it gets IETF rough consensus at Last Call, > of course.) Wouldn't we as part of the consensus process require an explanation why = any form of header or packet mangling is safe regardless of this = particular draft existing or not? Or am I missing something here? Ole From nobody Wed May 6 03:31:32 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C213A090C for ; Wed, 6 May 2020 03:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL8KOPMOitCl for ; Wed, 6 May 2020 03:31:28 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15803A090B for ; Wed, 6 May 2020 03:31:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jWHKm-0000JWC; Wed, 6 May 2020 12:31:24 +0200 Message-Id: To: ipv6@ietf.org Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com In-reply-to: Your message of "Tue, 5 May 2020 18:12:03 -0700 ." Date: Wed, 06 May 2020 12:31:21 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 10:31:31 -0000 >First off, the purpose of this draft is NOT to prevent future >"innovations" on using extension headers (especially in terms >of insertions and deletions) forever. Protocols evolve over time, and >RFCs have been and will be continuously updated or obsoleted with new >requirements, changes in assumptions, or "innovations". Even if this >draft intended to prevent such changes it wouldn't be impossible in >practice. I thought that's too obvious to mention, but if we really >worry about this draft to act as an "innovation blocker", we could add >the obvious note. I'm in favor of this draft, but I'm sad that this draft is necessary. We write our RFCs in English. Not some kind of formalized English, not legal English. Just plain, simple English. This comes with ambiguities. In my opinion the way to deal with with ambiguities is to explicitly writedown what you want to happen. Having an endless discussion what the words as the are written mean is counter productive. A few people mentioned innovations. I don't think innovations are served by vague, ambigous language. We have decades of experience with extensible protocols. In many cases we can explictly leave room for future developments. However, many big innovations cannot be forseen. For example, IPv4 NAT radically refined the IPv4 architecture. In those cases, we can either ignore that there is an issue with our standards, or we can adapt them. Of course, with any protocol that carries production data, we have to be careful with innovations to not impact existing systems. So I assumed that after the discusson surrounding the draft that became RFC 8200, the proponants of inserting routing headers along the path would write an RFC to update RFC 8200. This RFC should answers questions like what happens to PMTU discovery, what happens with authentication, error ICMPs. Ideally there would also be a justification why this is needed. I think that in the case of segment router, it can be explained why we don't expect negative effects. But somebody has to do the work writing that down in a way people outside the segment routing community can understand it. That would make it clear to any reader of RFC 8200, that header insertion does occur and why it has limited impact. Instead we got the argument that a particular reading of RFC 8200 would make header insertion possible. So I would very much like to see drafts that update RFC 8200 in new directions. However, given that that doesn't seem to be happening. The next best alternative is to clarify the language of RFC 8200 such that it is clear that header insertion is not possible without first updating RFC 8200. From nobody Wed May 6 04:08:22 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EC73A0946 for ; Wed, 6 May 2020 04:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GSW5fnIk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=k0mrMGFZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyA8twczgTEn for ; Wed, 6 May 2020 04:08:16 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6696F3A0645 for <6man@ietf.org>; Wed, 6 May 2020 04:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7887; q=dns/txt; s=iport; t=1588763296; x=1589972896; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=av0Ar/k5T3chN+fhHTpmpd67gtZxc0Ee1RAvQkafPMQ=; b=GSW5fnIkekEowIyVi0KvIaISfAk94s6/a/MknXMD11SBE7/sdEjQL5ny 5aC4fPqIzOeaPNIP81REEazjsvgxll5/9acVFazd6KCO2H1lzvk9G1CMv XdYt1X+mearbEeZnzdzZgF06eXafuTSXW9AsjksaoFexDIQeshU3ol4IP M=; IronPort-PHdr: =?us-ascii?q?9a23=3AgAOgFhTAkHbL8qxAybO1gZgwgdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9mJ5/dNkeGQsq38VyoH+5nS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4TsbAB?= =?us-ascii?q?65NAdpKKLyAIGBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COEQAzmrJe/5RdJa1mHgEBCxIMgyw?= =?us-ascii?q?vUQVuDkovKoQjg0YDizWCEZNShGOBQoEQA1QLAQEBDAEBLQIEAQGERAIXgWo?= =?us-ascii?q?kOBMCAwEBCwEBBQEBAQIBBQRthVYMhXEBAQEBAxIRHQEBOA8CAQgRAwECKwI?= =?us-ascii?q?CAjAdCAEBBAESIoMEAYF+TQMuAahuAoE5iGF2gTKDAAEBBYJJgloYgg4JgTi?= =?us-ascii?q?CY4lhGoFBP4E4HIJNPoJnBIEuARIBQYJyM4ItkUmGGppyCoJImBYdnSCQF50?= =?us-ascii?q?cAgQCBAUCDgEBBYFpImZwcBVlAYI+UBgNkEKDcopWdAI1AgYBBwEBAwl8kUo?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.73,358,1583193600"; d="scan'208,217";a="766697361" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2020 11:08:15 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 046B8FHL017291 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2020 11:08:15 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 06:08:15 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 07:08:13 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 6 May 2020 06:08:13 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ef/ncQrXvyu2FsKDnnsng/jOmn+fRtpAO4n5qVXWcEzH2kzQGIjlIR5nEm3mJTAuHfk+3RYGD/BTPUmB0jm+vD9CDqlKJgU7uhAliOJHsut0qrZ8Q7sAnTXV8lY/KW49N5v4JxSLgSMNa3LX+XGoY1sLLlUmukjixM7sKvzDzcJP9ZFpJvsM9xpXLbOuKzVTWTnx8U25xbNgcAg6eOPLBXgOCT7ZzZSNJF9rQ+treeBNRVgNA2R/zS5SSOy2yU/6GwpHZcqj/hi4X6F2xcg98L7DLB10Rw9+YF05MBKf64k3NowpmZcO5N66ZxU/m3fDa+nGzclDGXSPmX+D10b8nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=av0Ar/k5T3chN+fhHTpmpd67gtZxc0Ee1RAvQkafPMQ=; b=N0uy3rkmpsLLxuLvMNCDjSWVZVHK1gEW0lLPpaDQDUiNrWb9Uh5jBw4Zb+yd11SeVFlg0SDtZ0hbJ/GhhersX21A1JUBP+FDnRcuRZZqQ8rO3YdKF9Aw7bT7h5fYhsuCaU/pguWz0JDxmUoIWxGI+7imjUN/BqN3qXRcYlzhkI9Rwxh11M3qJZj8sDwEYR+aRNl04/eeLPz1XsKVPKABDHoUf/LHeuN4WLbyJeGeB1gczPGAOJsrZWBnYpG155vS9KXgscU4NHONRCIjD85XG3+KFgnX6zMI3jN8jBrWKvh791GFPP0q7qrTmAucTRpl8lfDBBJRz4hzdnEx7wJTGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=av0Ar/k5T3chN+fhHTpmpd67gtZxc0Ee1RAvQkafPMQ=; b=k0mrMGFZgKWpuV/Du2noO4UXC9Y9107KLeBuvjuyMNHMvCIBfOz6jKcermc5gcGo6HnUkHAH+0siF92m0BCc29fTgA+S/5UcjPasA360j1fdl+fNpOam1vyqQj49MSVrHiva83rpaSNSiH/JQP8GlN2bnmO70v7G2MrtV2BJP4g= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1498.namprd11.prod.outlook.com (2603:10b6:4:9::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.27; Wed, 6 May 2020 11:08:13 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c%9]) with mapi id 15.20.2979.028; Wed, 6 May 2020 11:08:13 +0000 From: "Eric Vyncke (evyncke)" To: Ron Bonica , 6man <6man@ietf.org> Subject: Re: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AdYjQANZ0MrEgFbBRG+Eev5I1WHYlQAZ2HwA Date: Wed, 6 May 2020 11:08:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:8c61:47ef:9ce5:3a3a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e11355f4-e3ff-45b0-b911-08d7f1adc4e7 x-ms-traffictypediagnostic: DM5PR11MB1498: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yfT3iuTRdJuMtl0110CXMaJZ/oTfy2M9Qcsg/gnpWpHuGBeRWpjh0DXtjN9LgQgm57YGhInd4y4EDeA+urvAkHvRFRpsjxd88txYqFZMlL73aas18+eRMASSAG8b1zigybW5Q+H4Bnlg6a2vAkhQ3zfWCuuOoHGz9Yzdv6/jtTPivxyeSKwpS7o4TRbputx3lW0YLk7R00RrZEoxjmvVVfOa6u6o5YT9SzBpATvwHQFjIXlWoejoUpWstttvIyzBwpTq7gJWKd7KUtalPR9w0E0C91w9N0ENZJur9JyZR9Vs7HEepBSityDrc39TEDvOHwohq1nFL4Ix/xjCdBX/0MNf9/gPTesw8ejeI6LZONT22tfxLRU6LdM5ECxwpX+C5nC69Zl9sUl6In4iG1v9FP4sXe3li4QzLWM2uFFhjrzqI5Zh3pX3QMjS0A5jOkOLmDUFBmjcoWhkTyhVqW+1BTVDhtgfj6Za2Xy35u06yfA3Jlm5nDRXukgL48JuoFS1iSB3P8MgLHTeVNhBsTJ68A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(346002)(39860400002)(136003)(366004)(33430700001)(6506007)(316002)(76116006)(53546011)(7116003)(33440700001)(3480700007)(186003)(478600001)(110136005)(91956017)(36756003)(33656002)(66476007)(71200400001)(66946007)(66556008)(6512007)(66446008)(5660300002)(6486002)(4744005)(8936002)(86362001)(2906002)(2616005)(8676002)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: VCl54LLaNkcb00O/qp+IGjcKAV6rDp7cZBjFs/kLVRP8h+00j9PzUBOtsh9DdXy+V69yHitavnc20ZzvuQs2PwEhCriZDHrqp8pS1fw0nmKMg0xO3eFb9bMWfx8jiz04asDj+r9MMLQmsAyz9L91ebN28+EGa0SDAJ0p75tFNWDDgOeXRPcVDSzFx/ymk8tGSXJHLl5OJD9/njjIEdu6o0NqGTXAFMk1lcpTfd3Ps55k9B+G9ti3YT4P3684ZBEEx+/+OVF2h8Rky4qOppGlAGM3xcNlGbHZ3ZbREi2j8eAMhF7CgOknc++X1AxziK+8Clx78p5UBoRgtzzBhQQ84xpSJWao5U3YTzsXdUg1jqRfeKJ/PZlbP8CcV97wR6S9i5C8xa1PGnvSm83EHURZfcHueqF3h1alWfbifybhkHC0M6zJB46va97ZgF06PsvmdD7NXNv/qdirQixU54sV7oakBWSnIkCRR8QwdUxUCcjwrgvd+KTixlOx6E35s1YTPw74M3za5SMDnFetKZAijpfwI8atdewqHr9N+cyGawqOWvL5OyRbvByVDFc7cVqm32N4N9fiYAb1NGiDsXWEu10/NYl+jlDNY0qfEOI+RnURY4fC83c4JH8e1gO+JddfsQmO2TNoKMkA848dkZvei7lPChy+Fi2cHo1ikDSdLBHunEQv/pPyC+qktpGbDLaYPlpHyk4XY4/lJbJFxezYVXXlIDJg7ewfrfmUz6W7O1bPgLN2COEgWb6jJFeRBiSwYygG3U/TKRQIYN2NdpTRV98sNW/ZrJe7CA55cNUcQBTSQRahMYW5jtZXFUTc1srRWWXErR7B5mDgnZaB8IixIkcXMvzbSGzZ30Jvijut4wg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AB9D493E72E5465D9FD4A801B9226B50ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e11355f4-e3ff-45b0-b911-08d7f1adc4e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 11:08:12.9891 (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: T3ps7heiYMjFxKmaaWx6HihRIYYwPDgzZEUGpm7lhT6vyg8mftFvNBVJ94BIehW0pe7s2dfHTTE2SEVaNsm4Ag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1498 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 11:08:20 -0000 --_000_AB9D493E72E5465D9FD4A801B9226B50ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9uLA0KDQpBbGwgbXkgcmVzcGVjdCB0byB5b3UgZm9yIHRoaXMgY29ycmVjdGlvbiBvZiB5b3Vy cy4NCg0KUmVnYXJkcw0KDQotw6lyaWMNCg0KUFM6IEkgd2FzIGFib3V0IHRvIHJlcGx5IHVuaWNh c3QgdG8gUm9uIGJ1dCBkZWNpZGVkIHRoYXQgUm9uIGRlc2VydmVzIHNvbWUgcHVibGljIGFwcHJl Y2lhdGlvbiBmb3IgaGlzIGVtYWlsLg0KDQpGcm9tOiBpcHY2IDxpcHY2LWJvdW5jZXNAaWV0Zi5v cmc+IG9uIGJlaGFsZiBvZiBSb24gQm9uaWNhIDxyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMu aWV0Zi5vcmc+DQpEYXRlOiBXZWRuZXNkYXksIDYgTWF5IDIwMjAgYXQgMDI6NTINClRvOiA2bWFu IDw2bWFuQGlldGYub3JnPg0KU3ViamVjdDogUm91dGluZyBIZWFkZXIgSW5zZXJ0aW9uDQoNCkZv bGtzLA0KDQpNeSBhcG9sb2dpZXMgdG8gWmFmYXIgQWxpLiBSZWFkaW5nIHRocm91Z2ggdGhlIEVB TlRDIHJlcG9ydCwgaXQgYXBwZWFycyB0aGUgSnVuaXBlciBkZW1vbnN0cmF0aW9uIFNSdjYgUm91 dGluZyBIZWFkZXIgaW5zZXJ0aW9uIHRvIHN1cHBvcnQgVEktTEZBLiBJbiB0aGF0IHJlc3BlY3Qs IFphZmFyIGlzIGNvcnJlY3QuDQoNCkhvd2V2ZXIsIHdlIHNob3VsZCBub3QganVtcCB0byB0aGUg Y29uY2x1c2lvbiB0aGF0IHN1Y2ggYmVoYXZpb3IgaXMgZGVzaXJhYmxlLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFJvbg0KDQoNCg0KSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KDQoNCkp1bmlwZXIgQnVz aW5lc3MgVXNlIE9ubHkNCg== --_000_AB9D493E72E5465D9FD4A801B9226B50ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <707A538808EE544B9566110A954B3FA6@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNpcGZvb3RlcjMwYjNkNTM4LCBsaS5tc2lwZm9vdGVyMzBiM2Q1 MzgsIGRpdi5tc2lwZm9vdGVyMzBiM2Q1MzgNCgl7bXNvLXN0eWxlLW5hbWU6bXNpcGZvb3RlcjMw YjNkNTM4Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVuLUJFIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPlJvbiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFs bCBteSByZXNwZWN0IHRvIHlvdSBmb3IgdGhpcyBjb3JyZWN0aW9uIG9mIHlvdXJzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LcOpcmljPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5QUzogSSB3YXMgYWJvdXQgdG8gcmVwbHkgdW5pY2FzdCB0byBSb24gYnV0IGRlY2lk ZWQgdGhhdCBSb24gZGVzZXJ2ZXMgc29tZSBwdWJsaWMgYXBwcmVjaWF0aW9uIGZvciBoaXMgZW1h aWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPmlwdjYgJmx0O2lwdjYtYm91bmNlc0BpZXRmLm9yZyZn dDsgb24gYmVoYWxmIG9mIFJvbiBCb25pY2EgJmx0O3Jib25pY2E9NDBqdW5pcGVyLm5ldEBkbWFy Yy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCA2IE1heSAyMDIwIGF0 IDAyOjUyPGJyPg0KPGI+VG86IDwvYj42bWFuICZsdDs2bWFuQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5Sb3V0aW5nIEhlYWRlciBJbnNlcnRpb248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Rm9sa3MsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPk15IGFwb2xvZ2llcyB0byBaYWZhciBBbGkuIFJlYWRpbmcgdGhyb3VnaCB0aGUgRUFOVEMg cmVwb3J0LCBpdCBhcHBlYXJzIHRoZSBKdW5pcGVyIGRlbW9uc3RyYXRpb24gU1J2NiBSb3V0aW5n IEhlYWRlciBpbnNlcnRpb24gdG8gc3VwcG9ydCBUSS1MRkEuIEluIHRoYXQgcmVzcGVjdCwgWmFm YXIgaXMgY29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SG93ZXZlciwgd2Ugc2hvdWxkIG5v dCBqdW1wIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgc3VjaCBiZWhhdmlvciBpcyBkZXNpcmFibGUu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSb248bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0ibXNpcGZvb3RlcjMw YjNkNTM4IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjM2LjBwdDttYXJnaW4t Ym90dG9tOi4wMDAxcHQ7dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtjb2xvcjpibGFjayI+SnVuaXBlciBCdXNpbmVzcyBVc2UgT25seTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dDttYXJnaW4tbGVmdDo0MS4wcHQ7dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+SnVuaXBlciBCdXNpbmVzcyBVc2UgT25seTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AB9D493E72E5465D9FD4A801B9226B50ciscocom_-- From nobody Wed May 6 05:09:28 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08783A09D7 for ; Wed, 6 May 2020 05:09:25 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 5b2lviE4Jtdu for ; Wed, 6 May 2020 05:09:24 -0700 (PDT) Received: from ESA1-Wyn.bell.ca (esa1-wyn.bell.ca [67.69.243.161]) (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 CBDD03A09BA for <6man@ietf.org>; Wed, 6 May 2020 05:09:23 -0700 (PDT) Subject: RE: Routing Header Insertion Received: from dm5cch-d00.bellca.int.bell.ca (HELO DG1MBX02-WYN.bell.corp.bce.ca) ([198.235.102.30]) by esa01corp-wyn.bell.corp.bce.ca with ESMTP; 06 May 2020 08:09:22 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX02-WYN.bell.corp.bce.ca (2002:8eb6:120c::8eb6:120c) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 08:09:21 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca ([fe80::6d54:4041:a00d:56d3]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::6d54:4041:a00d:56d3%22]) with mapi id 15.00.1497.006; Wed, 6 May 2020 08:09:21 -0400 From: "Voyer, Daniel" To: "Eric Vyncke (evyncke)" , Ron Bonica , 6man <6man@ietf.org> Thread-Topic: [EXT]Re: Routing Header Insertion Thread-Index: AQHWI58t0MrEgFbBRG+Eev5I1WHYlQ== Date: Wed, 6 May 2020 12:09:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.25.8] Content-Type: multipart/alternative; boundary="_000_B24125687DA44742844DB2E94114DC10bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 12:09:26 -0000 --_000_B24125687DA44742844DB2E94114DC10bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9uLCB5ZXMg4oCTIEkgZWNobyBFcmljIOKAkyBhbGwgbXkgcmVzcGVjdC4NCg0KUm9uLCBJIGZv ciBvbmUsIHdvdWxkIGp1bXAgdG8gY29uY2x1c2lvbiBmb3IgdGhhdCBzcGVjaWZpYyB1c2UgY2Fz ZSB3aGVyZSBpbnNlcnRpb24gaXMgcGVyZm9ybWVkLCBhbmQgaGF2ZSB0aGUgZXhwZWN0ZWQgYmVo YXZpb3VyLiBUaGlzIGlzIHRoZSBleGFjdCB1c2UgY2FzZSB0aGF0IHdhcyBkZXNjcmliZWQgb3Zl ciB0aGUgeWVhcnMgaW4gdGhpcyBtYWlsaW5nIGxpc3QsDQoNCk5vdywgb2J2aW91c2x5LCB0aGlz IHVzZSBjYXNlIGlzIGNvbnRhaW4gd2l0aGluIHRoZSBvcGVyYXRvciBkb21haW4uIEkgZG9u4oCZ dCBleHBlY3QgYW4gb3BlcmF0b3IgdG8gaGF2ZSDigJxUSS1MRkHigJ0gb24gdGhlaXIgcGVlcmlu ZyBsaW5rcyB3aXRoIG90aGVyIHRyYW5zaXQvb3BlcmF0b3IuDQoNCkZvciBwZW9wbGUgcmVmZXJl bmNlcywgcGFnZSAxNSDigJxUSS1MRkEgb3ZlciBTUnY24oCdOg0KaHR0cDovL3d3dy5lYW50Yy5k ZS9maWxlYWRtaW4vZWFudGMvZG93bmxvYWRzL2V2ZW50cy9NUExTMjAyMC9FQU5UQy1NUExTU0RO TkZWMjAyMC1XaGl0ZVBhcGVyLnBkZg0KDQpUaGFua3MsDQpkYW4NCg0KRnJvbTogaXB2NiA8aXB2 Ni1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIkVyaWMgVnluY2tlIChldnluY2tlKSIg PGV2eW5ja2U9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBXZWRuZXNkYXksIE1h eSA2LCAyMDIwIGF0IDc6MDggQU0NClRvOiBSb24gQm9uaWNhIDxyYm9uaWNhPTQwanVuaXBlci5u ZXRAZG1hcmMuaWV0Zi5vcmc+LCA2bWFuIDw2bWFuQGlldGYub3JnPg0KU3ViamVjdDogW0VYVF1S ZTogUm91dGluZyBIZWFkZXIgSW5zZXJ0aW9uDQoNClJvbiwNCg0KQWxsIG15IHJlc3BlY3QgdG8g eW91IGZvciB0aGlzIGNvcnJlY3Rpb24gb2YgeW91cnMuDQoNClJlZ2FyZHMNCg0KLcOpcmljDQoN ClBTOiBJIHdhcyBhYm91dCB0byByZXBseSB1bmljYXN0IHRvIFJvbiBidXQgZGVjaWRlZCB0aGF0 IFJvbiBkZXNlcnZlcyBzb21lIHB1YmxpYyBhcHByZWNpYXRpb24gZm9yIGhpcyBlbWFpbC4NCg0K RnJvbTogaXB2NiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUm9uIEJvbmlj YSA8cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPg0KRGF0ZTogV2VkbmVzZGF5 LCA2IE1heSAyMDIwIGF0IDAyOjUyDQpUbzogNm1hbiA8Nm1hbkBpZXRmLm9yZz4NClN1YmplY3Q6 IFJvdXRpbmcgSGVhZGVyIEluc2VydGlvbg0KDQpGb2xrcywNCg0KTXkgYXBvbG9naWVzIHRvIFph ZmFyIEFsaS4gUmVhZGluZyB0aHJvdWdoIHRoZSBFQU5UQyByZXBvcnQsIGl0IGFwcGVhcnMgdGhl IEp1bmlwZXIgZGVtb25zdHJhdGlvbiBTUnY2IFJvdXRpbmcgSGVhZGVyIGluc2VydGlvbiB0byBz dXBwb3J0IFRJLUxGQS4gSW4gdGhhdCByZXNwZWN0LCBaYWZhciBpcyBjb3JyZWN0Lg0KDQpIb3dl dmVyLCB3ZSBzaG91bGQgbm90IGp1bXAgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCBzdWNoIGJlaGF2 aW9yIGlzIGRlc2lyYWJsZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCg0KDQoNCkp1bmlwZXIgQnVz aW5lc3MgVXNlIE9ubHkNCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo= --_000_B24125687DA44742844DB2E94114DC10bellca_ Content-Type: text/html; charset="utf-8" Content-ID: <5AD83311634B14409B7A524C397B2850@exchange.bell.ca> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLm1zaXBmb290ZXIzMGIzZDUzOCwgbGkubXNpcGZvb3RlcjMwYjNkNTM4LCBkaXYubXNpcGZv b3RlcjMwYjNkNTM4DQoJe21zby1zdHlsZS1uYW1lOm1zaXBmb290ZXIzMGIzZDUzODsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlJvbiwgeWVzIOKAkyBJIGVjaG8gRXJpYyDigJMgYWxsIG15IHJlc3BlY3QuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlJvbiwgSSBmb3Igb25lLCB3b3VsZCBqdW1wIHRvIGNvbmNsdXNpb24g Zm9yIHRoYXQgc3BlY2lmaWMgdXNlIGNhc2Ugd2hlcmUgaW5zZXJ0aW9uIGlzIHBlcmZvcm1lZCwg YW5kIGhhdmUgdGhlIGV4cGVjdGVkIGJlaGF2aW91ci4gVGhpcyBpcyB0aGUgZXhhY3QgdXNlIGNh c2UgdGhhdCB3YXMgZGVzY3JpYmVkIG92ZXIgdGhlIHllYXJzIGluIHRoaXMgbWFpbGluZyBsaXN0 LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3csIG9idmlvdXNseSwgdGhpcyB1c2UgY2FzZSBp cyBjb250YWluIHdpdGhpbiB0aGUgb3BlcmF0b3IgZG9tYWluLiBJIGRvbuKAmXQgZXhwZWN0IGFu IG9wZXJhdG9yIHRvIGhhdmUg4oCcVEktTEZB4oCdIG9uIHRoZWlyIHBlZXJpbmcgbGlua3Mgd2l0 aCBvdGhlciB0cmFuc2l0L29wZXJhdG9yLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgcGVv cGxlIHJlZmVyZW5jZXMsIHBhZ2UgMTUg4oCcVEktTEZBIG92ZXIgU1J2NuKAnTo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuZWFudGMuZGUv ZmlsZWFkbWluL2VhbnRjL2Rvd25sb2Fkcy9ldmVudHMvTVBMUzIwMjAvRUFOVEMtTVBMU1NETk5G VjIwMjAtV2hpdGVQYXBlci5wZGYiPmh0dHA6Ly93d3cuZWFudGMuZGUvZmlsZWFkbWluL2VhbnRj L2Rvd25sb2Fkcy9ldmVudHMvTVBMUzIwMjAvRUFOVEMtTVBMU1NETk5GVjIwMjAtV2hpdGVQYXBl ci5wZGY8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+aXB2NiAmbHQ7aXB2Ni1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYg b2YgJnF1b3Q7RXJpYyBWeW5ja2UgKGV2eW5ja2UpJnF1b3Q7ICZsdDtldnluY2tlPTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIE1heSA2 LCAyMDIwIGF0IDc6MDggQU08YnI+DQo8Yj5UbzogPC9iPlJvbiBCb25pY2EgJmx0O3Jib25pY2E9 NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyZndDssIDZtYW4gJmx0OzZtYW5AaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltFWFRdUmU6IFJvdXRpbmcgSGVhZGVyIEluc2VydGlv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJGUiI+Um9uLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxsIG15IHJlc3BlY3QgdG8geW91 IGZvciB0aGlzIGNvcnJlY3Rpb24gb2YgeW91cnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4tw6lyaWM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBTOiBJIHdhcyBh Ym91dCB0byByZXBseSB1bmljYXN0IHRvIFJvbiBidXQgZGVjaWRlZCB0aGF0IFJvbiBkZXNlcnZl cyBzb21lIHB1YmxpYyBhcHByZWNpYXRpb24gZm9yIGhpcyBlbWFpbC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+aXB2NiAmbHQ7aXB2Ni1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgUm9u IEJvbmljYSAmbHQ7cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnJmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIDYgTWF5IDIwMjAgYXQgMDI6NTI8YnI+DQo8Yj5Ubzog PC9iPjZtYW4gJmx0OzZtYW5AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJvdXRp bmcgSGVhZGVyIEluc2VydGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5Gb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TXkgYXBvbG9naWVzIHRv IFphZmFyIEFsaS4gUmVhZGluZyB0aHJvdWdoIHRoZSBFQU5UQyByZXBvcnQsIGl0IGFwcGVhcnMg dGhlIEp1bmlwZXIgZGVtb25zdHJhdGlvbiBTUnY2IFJvdXRpbmcgSGVhZGVyIGluc2VydGlvbiB0 byBzdXBwb3J0IFRJLUxGQS4gSW4gdGhhdCByZXNwZWN0LCBaYWZhciBpcyBjb3JyZWN0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5Ib3dldmVyLCB3ZSBzaG91bGQgbm90IGp1bXAgdG8gdGhlIGNvbmNs dXNpb24gdGhhdCBzdWNoIGJlaGF2aW9yIGlzIGRlc2lyYWJsZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtc2lwZm9vdGVyMzBiM2Q1MzgiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTowY207bWFyZ2luLWxlZnQ6MzYuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0 LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNr Ij5KdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0 O21hcmdpbi1yaWdodDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0OjQxLjBw dDt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OmJsYWNrIj5KdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B24125687DA44742844DB2E94114DC10bellca_-- From nobody Wed May 6 05:36:48 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866D33A0AC7 for ; Wed, 6 May 2020 05:36:39 -0700 (PDT) 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 u1NUiUrQ0C2V for ; Wed, 6 May 2020 05:36:37 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 9A3913A0AD7 for <6man@ietf.org>; Wed, 6 May 2020 05:36:34 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id h12so2451251pjz.1 for <6man@ietf.org>; Wed, 06 May 2020 05:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qcg0776TEkt2NB+EPrI8l8R4cu9vXZEYOFyJPsrBLlY=; b=MRzCTDwxqfSzfOx+0roPclGO34S/eAIzh48IVYARxkFo+i6RYCySH8wm91Cb3ehfQa nW8f2nmb9XCMwngj+mqzX8bixcRIDRJQoali2M4Yewivusnrnsg5RtOFONMJtY2ZBtoa fDdvcLRp2ROxrGz0WPP8KqIh+9hgwdBo48LM5TVKxchehM1ARaZUx1DUZ0p79iAPR/3Y Mz+lBqbXWv68+B49rbDbsiYRC2MWRwjl07afVNRUoxIQhb8x7TZJ3pxumBTu2pidRNQD nzpGXps9zpERwg9OMsU8/qfPORK1zN98jKdPscQsu9Xstbe8t5v2Us1TFuKefCtssUNM SXmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qcg0776TEkt2NB+EPrI8l8R4cu9vXZEYOFyJPsrBLlY=; b=W7jDl90yPcLFMT2wnbeU5z4uP1fcDsPN8mcY8JoGRHIKDiTIW5ZHx4SZVK1u9SNbRO vIqcsFQqJpYGme4ZQxrfaBgjYoJ4BfLLs1UX4klTLzqOhbzhsepQ9Rfqc5szejdWBwjL MqR3LZRfs+7AEqa6ABwTUtT2+Y/tLwzbpr6AJ1Y5WkEUVUAZPol2ExjddCLySGfIi4gB nPKCnUdJhE8g6fj1agUvFlGvc0DHubOX1NCcJvUpca0Vwol6a6IdJfGxFEimCO3ZcTHI ypv2ZaOuq1/p3qZ4o0B3NMLrWtP+ztMYQLx+flHnZ2OhmSWDPu1GbkZkPFm/gDpahPoY TKhQ== X-Gm-Message-State: AGi0PuZMpXi4j8/wiAk4NusPAc2fKIWKox0f2IviPKATgKpm7nQuVem1 Jamat0Ec6j79z7A2LvVHX0FaDj+n X-Google-Smtp-Source: APiQypIOH4rTSdoWIOinRmQPWptvgSryANmX2tZHdjlh/750BzyjixDVt0VFaQ7j5JAOmor5YV16LQ== X-Received: by 2002:a17:902:47:: with SMTP id 65mr7160352pla.54.1588768593907; Wed, 06 May 2020 05:36:33 -0700 (PDT) Received: from kszarkowicz-mbp.jnpr.net (jpams-nat13.juniper.net. [193.110.49.13]) by smtp.gmail.com with ESMTPSA id n34sm1630015pgl.43.2020.05.06.05.36.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2020 05:36:32 -0700 (PDT) From: Krzysztof Szarkowicz Message-Id: <497430AB-1840-4320-991F-B4906607033E@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2F70B73A-43F5-4A6A-86D0-515989CA2E6F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Routing Header Insertion Date: Wed, 6 May 2020 14:36:28 +0200 In-Reply-To: Cc: "Eric Vyncke (evyncke)" , Ron Bonica , 6man <6man@ietf.org> To: "Voyer, Daniel" References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 12:36:46 -0000 --Apple-Mail=_2F70B73A-43F5-4A6A-86D0-515989CA2E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Also, There is short video discussing SRv6 TI-LFA EANTC test: https://youtu.be/v9woK-7AiyA Thanks, Krzysztof > On 2020 -May-06, at 14:09, Voyer, Daniel wrote: >=20 > Ron, yes =E2=80=93 I echo Eric =E2=80=93 all my respect. > =20 > Ron, I for one, would jump to conclusion for that specific use case = where insertion is performed, and have the expected behaviour. This is = the exact use case that was described over the years in this mailing = list, > =20 > Now, obviously, this use case is contain within the operator domain. I = don=E2=80=99t expect an operator to have =E2=80=9CTI-LFA=E2=80=9D on = their peering links with other transit/operator. > =20 > For people references, page 15 =E2=80=9CTI-LFA over SRv6=E2=80=9D: > = http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSD= NNFV2020-WhitePaper.pdf = > =20 > Thanks, > dan > =20 > From: ipv6 > on = behalf of "Eric Vyncke (evyncke)" > > Date: Wednesday, May 6, 2020 at 7:08 AM > To: Ron Bonica >, 6man <6man@ietf.org = > > Subject: [EXT]Re: Routing Header Insertion > =20 > Ron, > =20 > All my respect to you for this correction of yours. > =20 > Regards > =20 > -=C3=A9ric > =20 > PS: I was about to reply unicast to Ron but decided that Ron deserves = some public appreciation for his email. > =20 > From: ipv6 > on = behalf of Ron Bonica > > Date: Wednesday, 6 May 2020 at 02:52 > To: 6man <6man@ietf.org > > Subject: Routing Header Insertion > =20 > Folks, > =20 > My apologies to Zafar Ali. Reading through the EANTC report, it = appears the Juniper demonstration SRv6 Routing Header insertion to = support TI-LFA. In that respect, Zafar is correct. > =20 > However, we should not jump to the conclusion that such behavior is = desirable. > =20 > = Ron > =20 > =20 > Juniper Business Use Only > =20 > Juniper Business Use Only >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 = > -------------------------------------------------------------------- --Apple-Mail=_2F70B73A-43F5-4A6A-86D0-515989CA2E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Also,

There= is short video discussing SRv6 TI-LFA EANTC test:


Thanks,
Krzysztof

On 2020 -May-06, at 14:09, = Voyer, Daniel <daniel.voyer@bell.ca> wrote:

Ron, yes = =E2=80=93 I echo Eric =E2=80=93 all my respect.
 
Ron, I = for one, would jump to conclusion for that specific use case where = insertion is performed, and have the expected behaviour. This is the = exact use case that was described over the years in this mailing = list,
 
Now, = obviously, this use case is contain within the operator domain. I = don=E2=80=99t expect an operator to have =E2=80=9CTI-LFA=E2=80=9D on = their peering links with other transit/operator.
 
For = people references, page 15 =E2=80=9CTI-LFA over SRv6=E2=80=9D:
 
Thanks,
dan
 
From: ipv6 <ipv6-bounces@ietf.org> on = behalf of "Eric Vyncke (evyncke)" <evyncke=3D40cisco.com@dmarc.ietf.org>
Date: Wednesday, May 6, 2020 = at 7:08 AM
To: Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>, 6man <6man@ietf.org>
Subject: [EXT]Re: Routing Header = Insertion
 
Ron,
 
All my = respect to you for this correction of yours.
 
Regards
 
-=C3=A9ric
 
PS: I = was about to reply unicast to Ron but decided that Ron deserves some = public appreciation for his email.
 
From: ipv6 <ipv6-bounces@ietf.org> on = behalf of Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>
Date: Wednesday, 6 May 2020 = at 02:52
To: 6man <6man@ietf.org>
Subject: Routing Header = Insertion
 
Folks,
 
My apologies to Zafar Ali. Reading through the EANTC report, = it appears the Juniper demonstration SRv6 Routing Header insertion to = support TI-LFA. In that respect, Zafar is correct.
 
However, = we should not jump to the conclusion that such behavior is = desirable.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;           Ron
 
 

Juniper Business Use = Only

 

Juniper Business Use Only

---------------------------------------------------------------= -----
IETF IPv6 = working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
---------------------------------------------------------------= -----

= --Apple-Mail=_2F70B73A-43F5-4A6A-86D0-515989CA2E6F-- From nobody Wed May 6 07:12:02 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C774E3A0797 for ; Wed, 6 May 2020 07:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=U32hPaHp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uTbNQ6dm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6eVauR13N_t for ; Wed, 6 May 2020 07:11:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F12D3A0783 for <6man@ietf.org>; Wed, 6 May 2020 07:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6525; q=dns/txt; s=iport; t=1588774317; x=1589983917; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TSNxrWHuwItp5TTXnBRSusgi7wrpunDzGVBu51calPA=; b=U32hPaHpcSm/hEng3y+wax3fKpQPEU6WsU6y4JhjHQhuT39GnHqo51bP fKmHP8jQSDOhRes6Y4tHbO5bZxZ5DWzDRTsHpe3TcXAjZjUUx4+dSQszG pE2G6asa3GbpGYj0bJPAHi2MHpxQNkmwf9fiYaFOA9ZlLD7zIdoldTiYu 8=; IronPort-PHdr: =?us-ascii?q?9a23=3ADnDJARbbFBsejbyvR6kPcL//LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QWVD4ne4uhPzevbr66mXnYPst6Ns3EHJZpLUR?= =?us-ascii?q?JNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8XG35CQZXB?= =?us-ascii?q?TyKQQzIf76Scbeis2t3LW0/JveKwxDmDu6Z+Z0KxO75QXcv8Ubm81sMKE0nx?= =?us-ascii?q?DIuXBPPe9RwDBl?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOBgAwxLJe/4UNJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCB4ElL1EFbg5KLyoKhBmDRgONR5NShGOCUgNUCwEBAQwBAS0?= =?us-ascii?q?CBAEBhEQCF4FqJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVxAQEBAQMSER0BATc?= =?us-ascii?q?BDwIBCBEDAQIrAgICMB0IAQEEAQ0FIoMEAYF+TQMuAQKpFgKBOYhhdoEygwA?= =?us-ascii?q?BAQWCSYJVGIIOCYE4gmOJYRqBQT+BOByCTT6CZwSCA4JyM4ItkUmGGopskAY?= =?us-ascii?q?KgkiYFh2dIJAXnRwCBAIEBQIOAQEFgWkigVZwFWUBgj5QGA2QQoNyilZ0AjU?= =?us-ascii?q?CBgEHAQEDCXyQOgGBDwEB?= X-IronPort-AV: E=Sophos;i="5.73,359,1583193600"; d="scan'208,217";a="766769536" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2020 14:11:56 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 046EBudn022290 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2020 14:11:56 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 09:11:56 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 09:11:55 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 6 May 2020 10:11:55 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FD5eQG033HDp4vBiG3HiNY0z7rppElk1NfqmnShRK0X+Kgq5EcCHRrDh6a61SpgD5pFQzHqORNLTfLYQNRG/53EEF+K03jV9aJ2DoiBk0V+6Jeoio0je9mmKhdq1xEeEEFJWxUe2bONiC4kVkrQHhGkPIYI+XpGfBy8OV3y87t98QgGc9HDZDI1SP2BxdIS0xo+xuxZZsmDNgAu0ncE5owQjgOIbxa49oeHo2jQe6lyllQ6Xf+lOMycN1Rykbj/aQVgZnUBVI2+nGTzpC62wXTwfMLJeKf8oO9unW8o/oOBXnnmi95H2Gxe22wuO9yBlNdjDA1YcI66Qoiyaog+ySg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TSNxrWHuwItp5TTXnBRSusgi7wrpunDzGVBu51calPA=; b=YgR5PnaR+teZmwZPJIg4h0pBv7+Eb2Kj6TWtIxqx+7zM7tXWmAC3JavwmlJOuf2q3CLfIqrVUYfzAS8uJBAWgBwQ5lN92kUo4JWuNeudU0EVMX6CXqlEin5dIXogNCxa+lYONoxMhwfCy1DlZnUuIF8B11LhqFBNfkOcSH/8qGUWr88JgYw/aeeGbn+MS5ARkJXa46dfJYsKFPegebk0Y6T0ndtA44TMcaVRS9UTJzydylYjh0n47yGh2KXs2ZJQu1OFCboxrvcvXgOQ97R4vGzL6snfkl7V9W2mpJ3IxrmXlDx5yBJphLFhPa0wrDRSfIP6aiEwfVePxn71dO+F9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TSNxrWHuwItp5TTXnBRSusgi7wrpunDzGVBu51calPA=; b=uTbNQ6dm0VoF1VzB4aBLRomkYJJcDcBiEqj84av9MG/tpkZBUgSgstRj5hD+8Lcz/4sgvUN65beBD51y2ZoYJyuReX+B+7JmgNP2radP0oZ/8efNaOkNUoECUOF7YS3PElaRScmEQV8BSBh98FrllOQygSAJS5ULWZBlYARubfw= Received: from DM6PR11MB4692.namprd11.prod.outlook.com (2603:10b6:5:2aa::11) by DM6PR11MB4659.namprd11.prod.outlook.com (2603:10b6:5:2a5::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.21; Wed, 6 May 2020 14:11:54 +0000 Received: from DM6PR11MB4692.namprd11.prod.outlook.com ([fe80::6c2a:f5fa:44b9:f30b]) by DM6PR11MB4692.namprd11.prod.outlook.com ([fe80::6c2a:f5fa:44b9:f30b%3]) with mapi id 15.20.2979.028; Wed, 6 May 2020 14:11:54 +0000 From: "Zafar Ali (zali)" To: Ron Bonica , 6man <6man@ietf.org> Subject: Re: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AdYjQANZ0MrEgFbBRG+Eev5I1WHYlQATsBeA Date: Wed, 6 May 2020 14:11:54 +0000 Message-ID: <7671572C-6BCE-41D3-8BC5-1C247EF65EBC@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.36.20041300 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [47.185.212.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41a097f3-01cf-476a-4686-08d7f1c76e07 x-ms-traffictypediagnostic: DM6PR11MB4659: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jD+3VrfKcOD2kU8BF5PEQVZBdFTXgz7meJMDL+pdRUbhPtWMhth9Fr6JT2OaJIXLcc7lcPVhOoA8We0zlSuNu1bH1XSeoSu1jxyfJDd0C908jDbS8d4iGpz9tMwnEhPekUiR5LJo1jTmZ74ra57dl+UcbgsvNIsLTHGyFBKPNuySI+faE7gKc9Lqmt/vkls58+H2qJ3g8otb0vHIYnqlbfJYU93q+2ng7JJ5NiRWrpmvHFBU79TRq9Ir3Pu1+5a+mFZd+hPIRsLAGTqLHzlSWK8OtRieYlHZgnFIHFjwZAX98HF7veRofh9kcWSc9SE6bmkPC91P+tKxFAlviFXQ8tpW7/zzR39vQSEI6IfgR37XlkbhW9a9/o8Aa0JLU6mlPUprs5ssRYy6cJJclkZ9kcSj7FU4dYFq8aqrY3OjKcVber/ycrzqfYKJWKPBVP82JUgTdyxXfTR0uVYDgfLssdsuQ8T/W9Nqmykcq517UICoMBPUQ352dspgKJX2HtnLAbSgznayfdMCoCkZ/tjFUw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4692.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(346002)(136003)(376002)(396003)(33430700001)(4744005)(4326008)(53546011)(5660300002)(64756008)(6506007)(66446008)(6512007)(66946007)(76116006)(66476007)(107886003)(6486002)(33440700001)(66556008)(3480700007)(71200400001)(9326002)(7116003)(2616005)(478600001)(86362001)(2906002)(33656002)(110136005)(8936002)(36756003)(186003)(8676002)(316002)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: baE/KjVoh9S1pwzPc+r9WZhVmZHDYO/muKG4rL5fN4y/ygpH+Tm8FVdjpCvluFMWTwp4UaRFaRmYmpveeTHo/vbkBLAJ8lkEVJwKyONs2oVb13yvXBQBBH4vIeiMqg/PDRtMSAjKQQNZNUT/jBzx+eS5srBj5EFiU1njuda4ImMd7D/SrRG1Ph5UY4zUFvGKJdcpIHFYmU0e4dNVsx30hKS684IYe7bLQUBGg7coW6UF3NEk5y1q96SF/g874R/HKqRRcgMA8CHt3oIRYDOvNQ6vlbrdTefwuTnMgImF3jC0y16/z+8p3kiSirw86xFbAvf0+Imjv3C7eyIE66Fv2+hXp0dBfsaT+ynuruFgxIgBiH2OxJLmKal8xKt8E7SdoK94KdHI6+3jHIKDKEU4F0dx4lerXygwJc7YoTii+Ls9YGB9OCRv5DMLAAxelAnmrJvesatbGqjmAy5AyVtCL7HQAcY5AW4q8ZkEcXqYD/Sduu/FVrubfbWKuct6I8WWo1hdiuH/Z9UuDIxNCSE5BjWe/3qdQdz87ltd7yzZR0XHZKPOaQCz2vcc9U0Fc+iwTWk7xiziTnn+r1lga3H0bfbhwSFBQjrgZo3QEWjWoV6QDQXIXB9m3tIWBP/DJT/1KAb/CxK+53EzvZGemTfN1AWKo7r30BX6r6ZnDv2OxRdtIuBPMmNbVgifsh/bFPHnsa7r9bYqKG5+BoFq7cCxAnlUfWbMztuEiO9AecXRVFP5pjfecX/zJQ379hzOYJl5EayWp5rdD0dEtgiufpviColiUm367A1L9FV12pdmTRA= Content-Type: multipart/alternative; boundary="_000_7671572C6BCE41D38BC51C247EF65EBCciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 41a097f3-01cf-476a-4686-08d7f1c76e07 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 14:11:54.1925 (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: DKN8Xe4R30c0SVEiBA7741LV8vNcDI0y7s2WJzeY+KnAUgQOUl5RyIxBHF0uJmQR X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4659 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 14:12:00 -0000 --_000_7671572C6BCE41D38BC51C247EF65EBCciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9uLA0KDQpUaGFua3MgZm9yIHRoZSBhY2tub3dsZWRnZW1lbnQuDQoNClRoYW5rcw0KDQpS ZWdhcmRzIOKApiBaYWZhcg0KDQpGcm9tOiBpcHY2IDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmc+IG9u IGJlaGFsZiBvZiBSb24gQm9uaWNhIDxyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5v cmc+DQpEYXRlOiBUdWVzZGF5LCBNYXkgNSwgMjAyMCBhdCA4OjUxIFBNDQpUbzogNm1hbiA8Nm1h bkBpZXRmLm9yZz4NClN1YmplY3Q6IFJvdXRpbmcgSGVhZGVyIEluc2VydGlvbg0KDQpGb2xrcywN Cg0KTXkgYXBvbG9naWVzIHRvIFphZmFyIEFsaS4gUmVhZGluZyB0aHJvdWdoIHRoZSBFQU5UQyBy ZXBvcnQsIGl0IGFwcGVhcnMgdGhlIEp1bmlwZXIgZGVtb25zdHJhdGlvbiBTUnY2IFJvdXRpbmcg SGVhZGVyIGluc2VydGlvbiB0byBzdXBwb3J0IFRJLUxGQS4gSW4gdGhhdCByZXNwZWN0LCBaYWZh ciBpcyBjb3JyZWN0Lg0KDQpIb3dldmVyLCB3ZSBzaG91bGQgbm90IGp1bXAgdG8gdGhlIGNvbmNs dXNpb24gdGhhdCBzdWNoIGJlaGF2aW9yIGlzIGRlc2lyYWJsZS4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBS b24NCg0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCg0KDQpKdW5pcGVyIEJ1c2luZXNz IFVzZSBPbmx5DQo= --_000_7671572C6BCE41D38BC51C247EF65EBCciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNpcGZvb3RlcjMwYjNkNTM4LCBsaS5tc2lwZm9vdGVyMzBiM2Q1 MzgsIGRpdi5tc2lwZm9vdGVyMzBiM2Q1MzgNCgl7bXNvLXN0eWxlLW5hbWU6bXNpcGZvb3RlcjMw YjNkNTM4Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaSBSb24sIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRo ZSBhY2tub3dsZWRnZW1lbnQuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyDigKYgWmFmYXIgPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5pcHY2ICZsdDtpcHY2LWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBSb24gQm9uaWNhICZsdDtyYm9uaWNhPTQwanVu aXBlci5uZXRAZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE1h eSA1LCAyMDIwIGF0IDg6NTEgUE08YnI+DQo8Yj5UbzogPC9iPjZtYW4gJmx0OzZtYW5AaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJvdXRpbmcgSGVhZGVyIEluc2VydGlvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb2xrcyw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgYXBvbG9naWVzIHRvIFphZmFyIEFsaS4gUmVhZGlu ZyB0aHJvdWdoIHRoZSBFQU5UQyByZXBvcnQsIGl0IGFwcGVhcnMgdGhlIEp1bmlwZXIgZGVtb25z dHJhdGlvbiBTUnY2IFJvdXRpbmcgSGVhZGVyIGluc2VydGlvbiB0byBzdXBwb3J0IFRJLUxGQS4g SW4gdGhhdCByZXNwZWN0LCBaYWZhciBpcyBjb3JyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Ib3dldmVyLCB3ZSBzaG91bGQgbm90IGp1bXAgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCBzdWNo IGJlaGF2aW9yIGlzIGRlc2lyYWJsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFJvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtc2lwZm9vdGVyMzBiM2Q1MzgiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWFsaWduOmNlbnRlciI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj5KdW5pcGVyIEJ1c2luZXNz IFVzZSBPbmx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luOjUuMHB0 O3RleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJs YWNrIj5KdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7671572C6BCE41D38BC51C247EF65EBCciscocom_-- From nobody Wed May 6 13:31:14 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008A13A0B2C for ; Wed, 6 May 2020 13:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5elyGyXZVld for ; Wed, 6 May 2020 13:31:11 -0700 (PDT) Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 CEC2A3A0DC6 for <6man@ietf.org>; Wed, 6 May 2020 13:30:30 -0700 (PDT) Received: by mail-wm1-f48.google.com with SMTP id x4so3978652wmj.1 for <6man@ietf.org>; Wed, 06 May 2020 13:30:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sI/J3ZhmG4orerGxtzUJRf+mNU1Xbn4rHnpGp85BozI=; b=Asl2/X5zWrHOaXV+bYzFyzPiBsN6HvrqhNv5ot1oJpRERqUiKXqRSi4K+awGbwDZrb DNKWw/R/KTx+uuFnRvBcb1rayr8nyDCo34hoKaYUwjG9w6XsWWhrdxyNlA7rEVl8NIt5 TUvLH0w5jxhSKZ9JTJP31rZWKXSrCHbKqetdTwtwVb+ennDSjmzvkwD6Q2S9ojtbwgix YlPGewpZ+/f/61xfB6fWHCJ748RrjhVphigE1hCiUB+554RTgXur6d3ZpX8tlqIcxRMo mNRqhTcxCAd+dk2x2Pxu/ITU6Ie/Hn6O4atLTRDx/us3peGIiNCD9g3lmG7rx2lLDcZG k4og== X-Gm-Message-State: AGi0PubuBXS1RA3pdJTcq1tfmaJdC2QdEN+daGlds5PBCjvsKTvA572F gqvu0O0cnpHX6JRGpMrWHE4Vz/2XDfGp0XzNlys= X-Google-Smtp-Source: APiQypIvWgKRnpqLPS50MHcjovBndWdRf97p/GId4IHoO6qB1E/aBIoDkg/zBg1G/FN5VNrbi8Z4xEPJDJiB3asxaFQ= X-Received: by 2002:a7b:c44d:: with SMTP id l13mr6045371wmi.72.1588797029092; Wed, 06 May 2020 13:30:29 -0700 (PDT) MIME-Version: 1.0 References: <9865489e-ad29-5eb0-0dd8-370812d92b12@gmail.com> In-Reply-To: <9865489e-ad29-5eb0-0dd8-370812d92b12@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 6 May 2020 13:30:14 -0700 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Brian E Carpenter Cc: 6MAN <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 20:31:13 -0000 At Wed, 6 May 2020 14:52:45 +1200, Brian E Carpenter wrote: > If we clarify this with a MUST NOT strength, what does that mean? > It means (IMHO) that a specification which allows the MUST NOT to be > ignored needs to say so explicitly, and needs to explain why it's safe. Yes, that's what I hope this draft helps. I also hope it will help catch accidental violations of this MUST NOT in the process of standardization (even in a WG discussion, then WGLC, IESG evaluation, IETF LC). > Since all IETF standards are voluntary standards, it's hard to argue > that is unthinkable. It's difficult for me to parse this sentence due to the kind of double negation...do you mean that we should be able to expect the above "what it means" happens without the help of this draft? -- JINMEI, Tatuya From nobody Wed May 6 13:51:56 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E603A0B72 for ; Wed, 6 May 2020 13:51:53 -0700 (PDT) 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, FREEMAIL_FROM=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 NRn8ZnlmsS2o for ; Wed, 6 May 2020 13:51:50 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 BA86A3A0B7D for <6man@ietf.org>; Wed, 6 May 2020 13:51:50 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id s10so1089128plr.1 for <6man@ietf.org>; Wed, 06 May 2020 13:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TtDPEsHuhXLTdGkkZlol+qBpMh7ZfnXwBBT6qCBOZUE=; b=lMNWJiobajv5fsxCkIAVdXesil3g/3WK7//GRffCJXo8iMb2bDiNOhWy/TPQmzF87b 3r4PWaff9SqLZN5mRV+Q57FdwptHEnYS5rR1ArIwgmAqgg9YIF+HfQkvYu/gs/DlNJki CV19BhkkBDFAY3UBmnm7Smha2oS0Q9adEqHTlLmLrbFKeym9AwgKPgEee/cbMQAEQRAj WflxD3qWL7A2ZKeB3mvQIL3sj3gImIDfLi4uoY3dRAUSjqE5K9Lsp8ILaFOowlSIMG4U RSjLLddGA3m38YIUPQqO9xmqnuyN807nEFfd/NV6yvp5cSphQOm++J3SlRt00iGUqlX/ 52Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TtDPEsHuhXLTdGkkZlol+qBpMh7ZfnXwBBT6qCBOZUE=; b=UjXUpTGHSUlgahz+ScLtORz2QV09I1DFbdXbz2R1ZttYAl2pQNF/V6oSNXndPZdEV7 tqNUoCO0y5sROJj45RIeryXChvHtlrr396MRi13jSHzC37Kus2ZtGW0t4Rcz32lh5bdq eb101zsqzkmswtu3SeABh5c1gPCaD7REVvxUCKQJz7T+z+k+OOGCIY3nVlmRB/N6XjbE DGDrDdg+q5UZpQktXIJvrwg5FRC0bECJ8pdLsW+B5rAlrrDYc4HLTl2YH0HLKmlSy7vS 2Qw2YdaE2WbuORLCtLitapFQp+AAqUoU2+lAXE6uasvzjWdfd1uC13dEHR7RrK8yI9Zd wNsw== X-Gm-Message-State: AGi0PuYnccBm7xvOXf4olGk9RptIB+mjLLsLpeYt5imDrUMCwm35e34v 4eEpGUylJPnbBRi4/thuAha3s6BApFA= X-Google-Smtp-Source: APiQypKdxe0X46Ex7SvIeyCM9L1y8277jCcNWXWP+B2L/Frcc4WPT1eQyMWUSEvNOjbA9wSrXaC7ng== X-Received: by 2002:a17:90a:264b:: with SMTP id l69mr3860923pje.215.1588798309926; Wed, 06 May 2020 13:51:49 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.84]) by smtp.gmail.com with ESMTPSA id m19sm5593867pjv.30.2020.05.06.13.51.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2020 13:51:49 -0700 (PDT) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: otroan@employees.org Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , 6MAN <6man@ietf.org> References: <9865489e-ad29-5eb0-0dd8-370812d92b12@gmail.com> From: Brian E Carpenter Message-ID: <8ccabc79-fdeb-6be7-300f-6840944b5430@gmail.com> Date: Thu, 7 May 2020 08:51:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 20:51:54 -0000 Hi Ole, On 06-May-20 21:33, otroan@employees.org wrote: > > >> On 6 May 2020, at 04:52, Brian E Carpenter wrote: >> >> Due to the real world intervening, I had to drop off the meeting before >> this came up. So I appreciate this clarification. >> >>> Secondly, in a sense this draft indeed clarifies an "obvious" point: >>> "the node identified in the Destination Address field of the IPv6 >>> header" in Section 4 of RFC8200 means the ultimate destination, not an >>> intermediate node specified in a routing header, ... >> >> I do agree that this was my interpretation at the time, but as I already >> mentioned we completely forgot to consider the case of routing headers >> (also forgotten in RFC7045), so it is understandable that some readers >> made a different interpretation. >> >> If we clarify this with a MUST NOT strength, what does that mean? >> It means (IMHO) that a specification which allows the MUST NOT to be >> ignored needs to say so explicitly, and needs to explain why it's safe. >> Since all IETF standards are voluntary standards, it's hard to argue >> that is unthinkable. (If it gets IETF rough consensus at Last Call, >> of course.) > > Wouldn't we as part of the consensus process require an explanation why any form of header or packet mangling is safe regardless of this particular draft existing or not? > Or am I missing something here? No, I think your generalisation is correct (and has been an issue since RFC1631 or thereabouts). IPv6 header mangling is no different in that respect than IPv4 address mangling. Brian From nobody Wed May 6 13:54:53 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7997F3A0B0E for ; Wed, 6 May 2020 13:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 YwT9GNpPSqB6 for ; Wed, 6 May 2020 13:54:49 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 F27543A0B0C for <6man@ietf.org>; Wed, 6 May 2020 13:54:48 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id ms17so1544001pjb.0 for <6man@ietf.org>; Wed, 06 May 2020 13:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2U7iQxcl6KDs60OUifvj627mKrXpxCm7lCeqVCNIATI=; b=tE7mTvMTA7GVaiZAkOGVfpMYVbSgjBu6JFUGkcZuVLLvRChNyMv7eQ+ydb+ZIxp8TP /XFYPsF3mWu4fkaj4LuXm429lwu8n3Shkm6p8deh2IJrSoXQH3pcju7qF272g4GrPOuX qztsRUGTg1+4+klsNWemtNGv9etwtAovz+wHkuFXLbk8/MK0OvFM+ddF8Sx9tWnkGgqW Jju3MlkCfA3ZSwGg3xhFNDczBlp5DWfoMP9awp9CRHFHXOS/I/0ZYlFsOeHwFpVd6Y8V xA/a6u0apGiv300bER7XtT6IHi5CnGEdtrglSBkgvZm6BVp4xGs4GxL+CwkQZxrqngWl lxNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2U7iQxcl6KDs60OUifvj627mKrXpxCm7lCeqVCNIATI=; b=UMac0gcIY4MK9YbYzDVS3koesxG95Npo8JuiORKr+y3A8d5uywr2+RsrxYB22n5ian f7Ff5qsbAe6IB5OsuHz5RdxpFKKAsCwkwR31EcLxAq9eCagBQzey7HrGrxAwNl0U65N8 iavX8En9d+/WRiHiwZ28u4CqbdY8Oy99Iju5Tc/LXuQzpV6u9492tKhjaZacm25AM3AT O9PbVPuQP63CryZJutHvkvXNr16h0HSOSDTIAzyQsKfrDsFsgvwxCZFG/ggMBwAsuA6s DMyIr/Fvwe1xKkXNwMQHDzWp1DSUUk2Y0qAFCILUsL/ILxzhL0JkB5E1ELoBmMVj14NP UTEQ== X-Gm-Message-State: AGi0PuZVl9CSGXmmp1yPJ4HsRFAwqzon7/do4jLDEGkqBapq5xb8mdMa AZRbH6k8udp210s6ygfH9WzUJ0noy8E= X-Google-Smtp-Source: APiQypKeBqF5qfgZOYxcoNvubRiHAwZ93+8hYnNw239LgLrl2Ejnl6VMcqAdfsWeqb/dliwSBOj/CQ== X-Received: by 2002:a17:90a:718c:: with SMTP id i12mr10785381pjk.142.1588798488089; Wed, 06 May 2020 13:54:48 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.84]) by smtp.gmail.com with ESMTPSA id h12sm2698063pfq.176.2020.05.06.13.54.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2020 13:54:47 -0700 (PDT) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: 6MAN <6man@ietf.org> References: <9865489e-ad29-5eb0-0dd8-370812d92b12@gmail.com> From: Brian E Carpenter Message-ID: <3b982733-f18c-ab20-bd0d-39b7f12c14e1@gmail.com> Date: Thu, 7 May 2020 08:54:43 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 20:54:52 -0000 On 07-May-20 08:30, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Wed, 6 May 2020 14:52:45 +1200, > Brian E Carpenter wrote: >=20 >> If we clarify this with a MUST NOT strength, what does that mean? >> It means (IMHO) that a specification which allows the MUST NOT to be >> ignored needs to say so explicitly, and needs to explain why it's safe= =2E >=20 > Yes, that's what I hope this draft helps. I also hope it will help > catch accidental violations of this MUST NOT in the process of > standardization (even in a WG discussion, then WGLC, IESG evaluation, > IETF LC). >=20 >> Since all IETF standards are voluntary standards, it's hard to argue >> that is unthinkable. >=20 > It's difficult for me to parse this sentence due to the kind of double > negation... Sorry about that, I couldn't think of a more simple way to say it. > do you mean that we should be able to expect the above > "what it means" happens without the help of this draft? In the ideal world, yes. But in the real world I think it's better to publish your draft, to avoid future misunderstandings. Regards, Brian From nobody Wed May 6 18:27:48 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A1A3A0E0F for ; Wed, 6 May 2020 18:27:45 -0700 (PDT) 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, 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, 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 GrUgrUNbQ-oQ for ; Wed, 6 May 2020 18:27:44 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC723A0E14 for ; Wed, 6 May 2020 18:27:43 -0700 (PDT) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id C075883712C83F2D396C; Thu, 7 May 2020 09:27:41 +0800 (CST) Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id 0471ReGV037990; Thu, 7 May 2020 09:27:40 +0800 (GMT-8) (envelope-from liu.yao71@zte.com.cn) Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid203; Thu, 7 May 2020 09:27:40 +0800 (CST) Date: Thu, 7 May 2020 09:27:40 +0800 (CST) X-Zmail-TransId: 2af95eb3640c0aea3623 X-Mailer: Zmail v1.0 Message-ID: <202005070927402766121@zte.com.cn> In-Reply-To: References: F76FBD9E-49C0-4451-9F0E-37F92DFC58B7@gmail.com Mime-Version: 1.0 From: To: , Cc: Subject: =?UTF-8?B?UmU6QWdlbmRhIGZvciA2bWFuIEludGVyaW0gbWVldGluZyAgb24gNSBNYXkgMjAyMA==?= Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 0471ReGV037990 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 01:27:47 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQm9iICYgT2xlLA0KDQoNCkkgd29uZGVyICBpZiB0aGVyZSBpcyBhIGxpbmsgZm9yIGF1ZGlv IHJlY29yZGluZyBvZiB0aGlzIG1lZXRpbmcsIHNpbmNlIEkgY2Fubm90IGZpbmQgaXQgaW4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy82bWFuL21lZXRpbmdzLw0KDQoNClRoYW5rcyBh IGxvdCAhDQoNCg0KDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCg0KWUFPDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0K5Y6f5aeL6YKu5Lu2DQoNCg0KDQrlj5Hku7bkurrvvJpCb2JIaW5kZW4gPGJvYi5o aW5kZW5AZ21haWwuY29tPg0K5pS25Lu25Lq677yaSVB2NiBMaXN0IDxpcHY2QGlldGYub3JnPjsN CuaKhOmAgeS6uu+8mkJvYiBIaW5kZW4gPGJvYi5oaW5kZW5AZ21haWwuY29tPjsNCuaXpSDmnJ8g 77yaMjAyMOW5tDA15pyIMDHml6UgMDQ6NTQNCuS4uyDpopgg77yaQWdlbmRhIGZvciA2bWFuIElu dGVyaW0gbWVldGluZyAgb24gNSBNYXkgMjAyMA0KDQoNClRoZSBhZ2VuZGEgZm9yIHRoZSBtZWV0 aW5nIGNhbiBiZSBmb3VuZCBhdDoNCg0KICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvaW50ZXJpbS0yMDIwLTZtYW4tMDIvbWF0ZXJpYWxzL2FnZW5kYS1pbnRlcmltLTIwMjAt Nm1hbi0wMi02bWFuLTAxLmh0bWwNCg0KVGltZTogIDE1OjAwIC0gMTY6NTkgUERULCA1IE1heSAy MDIwIC8gMjI6MDAgLSAyMzo1OSBVVEMsIDUgTWF5IDIwMjANCg0KV2ViZXggaW5mbzoNCg0KICBo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZmI0NzI4MjU0NTAzNWEzMmU2 ODk0MDAwZmMxZmU5YWUNCiAgTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjE0IDA3NSAx NjgNCiAgTWVldGluZyBwYXNzd29yZDogN3lUanJ0Ym5UNzINCg0KV2UgYXJlIGxvb2tpbmcgZm9y IGEgbWludXRlIHRha2VyIGFuZCBqYWJiZXIgc2NyaWJlLg0KDQpTcGVha2VycyBwbGVhc2Ugc2Vu ZCB1cyBhIFBERiBvZiB5b3VyIHNsaWRlcyBieSBNb25kYXkgNCBNYXkgMjAyMCAxNzowMCBVVEMu DQoNCkJvYiAmIE9sZQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmcNCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZh bWlseTogQ2FsaWJyaSwgSGVsdmV0aWNhOyBmb250LXNpemU6IDE3cHg7IGxpbmUtaGVpZ2h0OiAy NC4yODU3MTUxMDMxNDk0cHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsi PkhpJm5ic3A7PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+Qm9iJm5ic3A7JmFtcDsm bmJzcDtPbGUsPC9zcGFuPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQt ZmFtaWx5OmFyaWFsOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTdweDsgbGluZS1oZWlnaHQ6 IDI0LjI4NTcxNTEwMzE0OTRweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyI+SSB3b25kZXIgJm5ic3A7aWYgdGhlcmUgaXMgYSBsaW5rIGZvciBhdWRpbyByZWNvcmRpbmcg b2YgdGhpcyBtZWV0aW5nLCBzaW5jZSBJIGNhbm5vdCBmaW5kIGl0IGluJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy82bWFuL21lZXRpbmdzLyI+PC9hPjxhIHRh cmdldD0iX2JsYW5rIiBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnLzZtYW4v bWVldGluZ3MvIj48L2E+PGEgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvd2cvNm1hbi9tZWV0aW5ncy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvd2cvNm1hbi9tZWV0aW5ncy88L2E+PC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0 cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij5UaGFua3MgYSBsb3QgITwvcD48cCBzdHlsZT0iZm9udC1z aXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6 MTRweDtmb250LWZhbWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwg NTEpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgSGVsdmV0aWNhOyBmb250LXNpemU6IDE3cHg7IGxp bmUtaGVpZ2h0OiAyNC4yODU3MTUxMDMxNDk0cHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs IDI1NSwgMjU1KTsiPkJlc3QmbmJzcDtSZWdhcmRzLDwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQt c2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEs IDUxLCA1MSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTdw eDsgbGluZS1oZWlnaHQ6IDI0LjI4NTcxNTEwMzE0OTRweDsgYmFja2dyb3VuZC1jb2xvcjogcmdi KDI1NSwgMjU1LCAyNTUpOyI+WUFPPC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250 LWZhbWlseTphcmlhbDsiPjxicj48L3A+PGRpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeVJvdyIgc3R5 bGU9ImRpc3BsYXk6YmxvY2siPjxkaXYgY2xhc3M9InpoaXN0b3J5RGVzIiBzdHlsZT0id2lkdGg6 IDEwMCU7IGhlaWdodDogMjhweDsgbGluZS1oZWlnaHQ6IDI4cHg7IGJhY2tncm91bmQtY29sb3I6 ICNFMEU1RTk7IGNvbG9yOiAjMTM4OEZGOyB0ZXh0LWFsaWduOiBjZW50ZXI7IiBsYW5ndWFnZS1k YXRhPSJIaXN0b3J5T3JnVHh0Ij7ljp/lp4vpgq7ku7Y8L2Rpdj48ZGl2IGlkPSJ6d3JpdGVIaXN0 b3J5Q29udGFpbmVyIj48ZGl2IGNsYXNzPSJjb250cm9sLWdyb3VwIHpoaXN0b3J5UGFuZWwiPjxk aXYgY2xhc3M9InpoaXN0b3J5SGVhZGVyIiBzdHlsZT0icGFkZGluZzogOHB4OyBiYWNrZ3JvdW5k LWNvbG9yOiAjRjVGNkY4OyI+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlTZW5k ZXJUeHQiPuWPkeS7tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIj5C b2JIaW5kZW4gJmx0O2JvYi5oaW5kZW5AZ21haWwuY29tJmd0Ozwvc3Bhbj48L2Rpdj48ZGl2Pjxz dHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVRPVHh0Ij7mlLbku7bkurrvvJo8L3N0cm9uZz48 c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPklQdjYg TGlzdCAmbHQ7aXB2NkBpZXRmLm9yZyZndDs7PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5n dWFnZS1kYXRhPSJIaXN0b3J5Q0NUeHQiPuaKhOmAgeS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNz PSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+Qm9iIEhpbmRlbiAmbHQ7 Ym9iLmhpbmRlbkBnbWFpbC5jb20mZ3Q7Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3Vh Z2UtZGF0YT0iSGlzdG9yeURhdGVUeHQiPuaXpSDmnJ8g77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9 IiI+MjAyMOW5tDA15pyIMDHml6UgMDQ6NTQ8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1 YWdlLWRhdGE9Ikhpc3RvcnlTdWJqZWN0VHh0Ij7kuLsg6aKYIO+8mjwvc3Ryb25nPjxzcGFuIGNs YXNzPSJ6cmVhZFRpdGxlIj48c3Ryb25nPkFnZW5kYSBmb3IgNm1hbiBJbnRlcmltIG1lZXRpbmcg Jm5ic3A7b24gNSBNYXkgMjAyMDwvc3Ryb25nPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNz PSJ6aGlzdG9yeUNvbnRlbnQiPjxkaXY+VGhlJm5ic3A7YWdlbmRhJm5ic3A7Zm9yJm5ic3A7dGhl Jm5ic3A7bWVldGluZyZuYnNwO2NhbiZuYnNwO2JlJm5ic3A7Zm91bmQmbmJzcDthdDo8YnI+PGJy PiZuYnNwOyZuYnNwO2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmlt LTIwMjAtNm1hbi0wMi9tYXRlcmlhbHMvYWdlbmRhLWludGVyaW0tMjAyMC02bWFuLTAyLTZtYW4t MDEuaHRtbDxicj48YnI+VGltZTombmJzcDsmbmJzcDsxNTowMCZuYnNwOy0mbmJzcDsxNjo1OSZu YnNwO1BEVCwmbmJzcDs1Jm5ic3A7TWF5Jm5ic3A7MjAyMCZuYnNwOy8mbmJzcDsyMjowMCZuYnNw Oy0mbmJzcDsyMzo1OSZuYnNwO1VUQywmbmJzcDs1Jm5ic3A7TWF5Jm5ic3A7MjAyMDxicj48YnI+ V2ViZXgmbmJzcDtpbmZvOjxicj48YnI+Jm5ic3A7Jm5ic3A7aHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bWZiNDcyODI1NDUwMzVhMzJlNjg5NDAwMGZjMWZlOWFlPGJyPiZu YnNwOyZuYnNwO01lZXRpbmcmbmJzcDtudW1iZXImbmJzcDsoYWNjZXNzJm5ic3A7Y29kZSk6Jm5i c3A7NjE0Jm5ic3A7MDc1Jm5ic3A7MTY4PGJyPiZuYnNwOyZuYnNwO01lZXRpbmcmbmJzcDtwYXNz d29yZDombmJzcDs3eVRqcnRiblQ3Mjxicj48YnI+V2UmbmJzcDthcmUmbmJzcDtsb29raW5nJm5i c3A7Zm9yJm5ic3A7YSZuYnNwO21pbnV0ZSZuYnNwO3Rha2VyJm5ic3A7YW5kJm5ic3A7amFiYmVy Jm5ic3A7c2NyaWJlLjxicj48YnI+U3BlYWtlcnMmbmJzcDtwbGVhc2UmbmJzcDtzZW5kJm5ic3A7 dXMmbmJzcDthJm5ic3A7UERGJm5ic3A7b2YmbmJzcDt5b3VyJm5ic3A7c2xpZGVzJm5ic3A7Ynkm bmJzcDtNb25kYXkmbmJzcDs0Jm5ic3A7TWF5Jm5ic3A7MjAyMCZuYnNwOzE3OjAwJm5ic3A7VVRD Ljxicj48YnI+Qm9iJm5ic3A7JmFtcDsmbmJzcDtPbGU8YnI+PGJyPjxicj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj5JRVRGJm5ic3A7SVB2NiZuYnNwO3dvcmtpbmcmbmJzcDtncm91cCZuYnNwO21haWxpbmcmbmJz cDtsaXN0PGJyPmlwdjZAaWV0Zi5vcmc8YnI+QWRtaW5pc3RyYXRpdmUmbmJzcDtSZXF1ZXN0czom bmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8YnI+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+PGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwPjxicj48 L3A+PC9kaXY+ --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Wed May 6 19:11:24 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2B03A03F1 for ; Wed, 6 May 2020 19:11:22 -0700 (PDT) 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_DNSWL_BLOCKED=0.001, 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 3ARU2gv8yoQl for ; Wed, 6 May 2020 19:11:19 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FAB3A0365 for <6man@ietf.org>; Wed, 6 May 2020 19:11:18 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 07B9380476; Thu, 7 May 2020 04:11:14 +0200 (CEST) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: otroan@employees.org, Brian E Carpenter Cc: 6MAN <6man@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <9865489e-ad29-5eb0-0dd8-370812d92b12@gmail.com> From: Fernando Gont Message-ID: Date: Wed, 6 May 2020 23:11:08 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 02:11:23 -0000 On 6/5/20 06:33, otroan@employees.org wrote: > > >> On 6 May 2020, at 04:52, Brian E Carpenter wrote: >> >> Due to the real world intervening, I had to drop off the meeting before >> this came up. So I appreciate this clarification. >> >>> Secondly, in a sense this draft indeed clarifies an "obvious" point: >>> "the node identified in the Destination Address field of the IPv6 >>> header" in Section 4 of RFC8200 means the ultimate destination, not an >>> intermediate node specified in a routing header, ... >> >> I do agree that this was my interpretation at the time, but as I already >> mentioned we completely forgot to consider the case of routing headers >> (also forgotten in RFC7045), so it is understandable that some readers >> made a different interpretation. >> >> If we clarify this with a MUST NOT strength, what does that mean? >> It means (IMHO) that a specification which allows the MUST NOT to be >> ignored needs to say so explicitly, and needs to explain why it's safe. >> Since all IETF standards are voluntary standards, it's hard to argue >> that is unthinkable. (If it gets IETF rough consensus at Last Call, >> of course.) > > Wouldn't we as part of the consensus process require an explanation why any form of header or packet mangling is safe regardless of this particular draft existing or not? > Or am I missing something here? There's a claim that the specification is ambiguous, and, while for virtually everyone involved in rfc2460bis it was and is clear the intent of the meaning, in retrospective, the resulting text is sloppy. This draft, and the errata I've submitted on the topic, try to fix that. I personally believe that, being a bug for which the intent is and was clear, it can be done with an erratum (and, indeed, there's pending processing of an erratum I've submitted). This shouldn't require consensus. But, if folks want to fix this problem with a draft (such as this one), I don't mind. That's fine. Once we have a clean slate, folks proposing to change the status quo can certainly submit a draft, and argue for a change. That's normal workflow for any IETF wg. P.S.: whether this latter draft is within the charter of 6man is a different question. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed May 6 19:19:29 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0863A03F3 for ; Wed, 6 May 2020 19:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xTiplD_a16cX for ; Wed, 6 May 2020 19:19:23 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66ED73A005C for ; Wed, 6 May 2020 19:19:23 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5C0C18049D; Thu, 7 May 2020 04:19:20 +0200 (CEST) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Philip Homburg , ipv6@ietf.org Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: From: Fernando Gont Message-ID: <08019473-ae28-1591-40dd-b7790d89c877@si6networks.com> Date: Wed, 6 May 2020 23:13:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 02:19:27 -0000 Hello, Philip, Completely agree with you. Thanks, Fernando On 6/5/20 07:31, Philip Homburg wrote: >> First off, the purpose of this draft is NOT to prevent future >> "innovations" on using extension headers (especially in terms >> of insertions and deletions) forever. Protocols evolve over time, and >> RFCs have been and will be continuously updated or obsoleted with new >> requirements, changes in assumptions, or "innovations". Even if this >> draft intended to prevent such changes it wouldn't be impossible in >> practice. I thought that's too obvious to mention, but if we really >> worry about this draft to act as an "innovation blocker", we could add >> the obvious note. > > I'm in favor of this draft, but I'm sad that this draft is necessary. > > We write our RFCs in English. Not some kind of formalized English, not legal > English. Just plain, simple English. > > This comes with ambiguities. In my opinion the way to deal with with > ambiguities is to explicitly writedown what you want to happen. Having an > endless discussion what the words as the are written mean is counter > productive. > > A few people mentioned innovations. I don't think innovations are served by > vague, ambigous language. We have decades of experience with extensible > protocols. In many cases we can explictly leave room for future developments. > > However, many big innovations cannot be forseen. For example, IPv4 NAT > radically refined the IPv4 architecture. In those cases, we can either > ignore that there is an issue with our standards, or we can adapt them. > Of course, with any protocol that carries production data, we have to be > careful with innovations to not impact existing systems. > > So I assumed that after the discusson surrounding the draft that became RFC > 8200, the proponants of inserting routing headers along the path would > write an RFC to update RFC 8200. > > This RFC should answers questions like what happens to PMTU discovery, > what happens with authentication, error ICMPs. Ideally there would also be > a justification why this is needed. I think that in the case of segment router, > it can be explained why we don't expect negative effects. But somebody has > to do the work writing that down in a way people outside the segment > routing community can understand it. > > That would make it clear to any reader of RFC 8200, that header insertion > does occur and why it has limited impact. > > Instead we got the argument that a particular reading of RFC 8200 would make > header insertion possible. > > So I would very much like to see drafts that update RFC 8200 in new directions. > However, given that that doesn't seem to be happening. The next best > alternative is to clarify the language of RFC 8200 such that it is clear that > header insertion is not possible without first updating RFC 8200. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > . > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed May 6 20:06:29 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E3C3A048D for ; Wed, 6 May 2020 20:06:27 -0700 (PDT) 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, FREEMAIL_FROM=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 tJlnDh7CB7-m for ; Wed, 6 May 2020 20:06:25 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 131EF3A03FE for ; Wed, 6 May 2020 20:06:25 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id z8so4521478wrw.3 for ; Wed, 06 May 2020 20:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cfTbkudQUmEqnGrnfvj66Ifp5qOyBjV5nPhOch81FF0=; b=MiMNBG/mdsyYyf0UXqMTAfRRvmQR2ylT0YPwXLyBdzRLkdOt+KMJYUGht7J/HaRePl BnB2bRRY/Y2cdCeF99/0ctr7kU8La11sP6pAL6YacwxGHJHcrQZVaEuUXKfGgGn/3vic ljbWHlURGVJlOzVGx1MsBFtPdfCFx33MR1UK0ebARRGMquDoIc3hKlh247oVtDhDvB/c vbctI//ys3PzY/WOgbVgiabbF9LHct6vJ1acnVL1uhLUcRaHunsMKGmXGjQey1NoQzLv X3jATUPlJVmX70rdcVg9NX96qCFx8VOkQjXDFxmtF8C/D9o9wNwzkL6vX7qzkKfXGAkV Mw0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cfTbkudQUmEqnGrnfvj66Ifp5qOyBjV5nPhOch81FF0=; b=ozZH6H1pY1ut3BAJHUydNH6CykaAttZ1MmhnIc2Xl/HYrwoktXPB3u50jm4I/o+1+M xjvodS6gYSQaxUlQCEV3ypNC6o9unByK6fq2CXe13eufAj6f/QW8tFLoRD0o5wwtiwbp a+IWzv3wH56x9W+MsaZZQowPZLuQ4cjCXyXHgNDoHPS5rlDHyCgwtOPxFt8rrrym1wEh WX4KmO7ogKCbkrnKpCdmGjaqsvZIVW3yDikjsdqSrsocI6Tu2/frRcSQJgM9CPgCqGHT z6lHS9vNbM2778xyUfv0WZ/49CjAiHc5eooeE0bfTk9QLX8UYrL1GWEbLMMBjrHLWzaC rfBw== X-Gm-Message-State: AGi0Pub7qbLDUEGFApi1/2MlNu7WRxGMMJ4kW/j/4pbrXqwoN/vDaCho hLVh9tx43xbgdnoST/jZMAE= X-Google-Smtp-Source: APiQypKOWXKVZisWTmkpxKPmLLSQsp5HnVnypFyx7AfJkYlTvcQMSz+aRulCpa++iDv5+XM3fWz2QA== X-Received: by 2002:a5d:6a92:: with SMTP id s18mr11872853wru.50.1588820783531; Wed, 06 May 2020 20:06:23 -0700 (PDT) Received: from ?IPv6:2601:647:5a00:ef0b:c02e:31be:e0d9:cc77? ([2601:647:5a00:ef0b:c02e:31be:e0d9:cc77]) by smtp.gmail.com with ESMTPSA id z11sm5562352wro.48.2020.05.06.20.06.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2020 20:06:22 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_630DBB46-6CE8-4DC5-A37F-819D5C982D60"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: Agenda for 6man Interim meeting on 5 May 2020 Date: Wed, 6 May 2020 20:06:21 -0700 In-Reply-To: <202005070927402766121@zte.com.cn> Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= , IPv6 List To: liu.yao71@zte.com.cn References: <202005070927402766121@zte.com.cn> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 03:06:27 -0000 --Apple-Mail=_630DBB46-6CE8-4DC5-A37F-819D5C982D60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yao, I will see what I can find out and be back in touch. Bob > On May 6, 2020, at 6:27 PM, liu.yao71@zte.com.cn wrote: >=20 > Hi Bob & Ole, >=20 > I wonder if there is a link for audio recording of this meeting, = since I cannot find it in https://datatracker.ietf.org/wg/6man/meetings/ >=20 > Thanks a lot ! >=20 >=20 >=20 > Best Regards, >=20 > YAO >=20 >=20 >=20 >=20 >=20 > =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ABobHinden > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AIPv6 List ; > =E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9ABob Hinden ; > =E6=97=A5 =E6=9C=9F =EF=BC=9A2020=E5=B9=B405=E6=9C=8801=E6=97=A5 04:54 > =E4=B8=BB =E9=A2=98 =EF=BC=9AAgenda for 6man Interim meeting on 5 May = 2020 > The agenda for the meeting can be found at: >=20 > = https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/agenda= -interim-2020-6man-02-6man-01.html >=20 > Time: 15:00 - 16:59 PDT, 5 May 2020 / 22:00 - 23:59 UTC, 5 May 2020 >=20 > Webex info: >=20 > = https://ietf.webex.com/ietf/j.php?MTID=3Dmfb47282545035a32e6894000fc1fe9ae= > Meeting number (access code): 614 075 168 > Meeting password: 7yTjrtbnT72 >=20 > We are looking for a minute taker and jabber scribe. >=20 > Speakers please send us a PDF of your slides by Monday 4 May 2020 = 17:00 UTC. >=20 > Bob & Ole >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 >=20 --Apple-Mail=_630DBB46-6CE8-4DC5-A37F-819D5C982D60 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl6zey0ACgkQrut0EXfn u6jhAwgAkImi97B+gZWa5cc6s/DN+WFAMA25HLZJtolRb+spIZgue7WjrzzjnkqZ nHjCNYEXr4Ssw3rAfBq0OIzd5RMSVdWkuMeB1+X+jYYUOSaZgwn2J9Bqf8BdDPUm CmCJLlffySwe9OItT2TQSVjKpRxkZBIDvJy1PF+EpvdIFcNGoPGH2Hbyg3BJcqHU rX7d4WGdtl99Nl9VZR9pg0oCvgVeID8KEZmZVw7iI6roMkA/xkG1L+WAzUajiUsA F4vRUbHMjai/zEME6jyAragr3sgFbtw1wlLlCzW9mkJ57+FmA5atcgS6jgpQzyTb PyxXjmCfNnbDcj46ca5OhFUGThMWWQ== =n+Gr -----END PGP SIGNATURE----- --Apple-Mail=_630DBB46-6CE8-4DC5-A37F-819D5C982D60-- From nobody Thu May 7 02:08:37 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125453A0AAA for ; Thu, 7 May 2020 02:08:36 -0700 (PDT) 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, 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, 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 9Gh5l1dztv44 for ; Thu, 7 May 2020 02:08:34 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF9E3A0AA7 for ; Thu, 7 May 2020 02:08:33 -0700 (PDT) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 641C24AF590D6F300309; Thu, 7 May 2020 17:08:30 +0800 (CST) Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl2.zte.com.cn with SMTP id 04794G53039177; Thu, 7 May 2020 17:04:16 +0800 (GMT-8) (envelope-from liu.yao71@zte.com.cn) Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid203; Thu, 7 May 2020 17:04:15 +0800 (CST) Date: Thu, 7 May 2020 17:04:15 +0800 (CST) X-Zmail-TransId: 2af95eb3cf0fa9bdbcdb X-Mailer: Zmail v1.0 Message-ID: <202005071704159795976@zte.com.cn> In-Reply-To: References: F76FBD9E-49C0-4451-9F0E-37F92DFC58B7@gmail.com, C3C72231-29CF-424F-ABA1-66B6CE7E3998@gmail.com Mime-Version: 1.0 From: To: Cc: , , Subject: =?UTF-8?B?UmU6QWdlbmRhIGZvciA2bWFuIEludGVyaW0gbWVldGluZyAgb24gNSBNYXkgMjAyMA==?= Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 04794G53039177 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 09:08:36 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQm9i77yMDQoNCg0KIFRoYW5rIHlvdSBpbiBhZHZhbmNl77yBDQoNCg0KDQoNCg0KDQogUmVn YXJkcywgWUFPDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K5Y6f5aeL6YKu5Lu2DQoNCg0KDQrlj5Hk u7bkurrvvJpCb2JIaW5kZW4gPGJvYi5oaW5kZW5AZ21haWwuY29tPg0K5pS25Lu25Lq677ya5YiY 5bCnMDAxNjUyODY7DQrmioTpgIHkurrvvJpCb2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWlsLmNv bT47T2xlIFRyw7hhbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc+O0lQdjYgTGlzdCA8aXB2NkBpZXRm Lm9yZz47DQrml6Ug5pyfIO+8mjIwMjDlubQwNeaciDA35pelIDExOjA2DQrkuLsg6aKYIO+8mlJl OiBBZ2VuZGEgZm9yIDZtYW4gSW50ZXJpbSBtZWV0aW5nICBvbiA1IE1heSAyMDIwDQoNCg0KWWFv LA0KDQpJIHdpbGwgc2VlIHdoYXQgSSBjYW4gZmluZCBvdXQgYW5kIGJlIGJhY2sgaW4gdG91Y2gu DQoNCkJvYg0KDQoNCj4gT24gTWF5IDYsIDIwMjAsIGF0IDY6MjcgUE0sIGxpdS55YW83MUB6dGUu Y29tLmNuIHdyb3RlOg0KPiANCj4gSGkgQm9iICYgT2xlLA0KPiANCj4gSSB3b25kZXIgIGlmIHRo ZXJlIGlzIGEgbGluayBmb3IgYXVkaW8gcmVjb3JkaW5nIG9mIHRoaXMgbWVldGluZywgc2luY2Ug SSBjYW5ub3QgZmluZCBpdCBpbiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnLzZtYW4v bWVldGluZ3MvDQo+IA0KPiBUaGFua3MgYSBsb3QgIQ0KPiANCj4gDQo+IA0KPiBCZXN0IFJlZ2Fy ZHMsDQo+IA0KPiBZQU8NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiDljp/lp4vpgq7ku7YNCj4g5Y+R 5Lu25Lq677yaQm9iSGluZGVuIDxib2IuaGluZGVuQGdtYWlsLmNvbT4NCj4g5pS25Lu25Lq677ya SVB2NiBMaXN0IDxpcHY2QGlldGYub3JnPjsNCj4g5oqE6YCB5Lq677yaQm9iIEhpbmRlbiA8Ym9i LmhpbmRlbkBnbWFpbC5jb20+Ow0KPiDml6Ug5pyfIO+8mjIwMjDlubQwNeaciDAx5pelIDA0OjU0 DQo+IOS4uyDpopgg77yaQWdlbmRhIGZvciA2bWFuIEludGVyaW0gbWVldGluZyAgb24gNSBNYXkg MjAyMA0KPiBUaGUgYWdlbmRhIGZvciB0aGUgbWVldGluZyBjYW4gYmUgZm91bmQgYXQ6DQo+IA0K PiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjAtNm1h bi0wMi9tYXRlcmlhbHMvYWdlbmRhLWludGVyaW0tMjAyMC02bWFuLTAyLTZtYW4tMDEuaHRtbA0K PiANCj4gVGltZTogIDE1OjAwIC0gMTY6NTkgUERULCA1IE1heSAyMDIwIC8gMjI6MDAgLSAyMzo1 OSBVVEMsIDUgTWF5IDIwMjANCj4gDQo+IFdlYmV4IGluZm86DQo+IA0KPiAgIGh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1mYjQ3MjgyNTQ1MDM1YTMyZTY4OTQwMDBmYzFm ZTlhZQ0KPiAgIE1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDYxNCAwNzUgMTY4DQo+ICAg TWVldGluZyBwYXNzd29yZDogN3lUanJ0Ym5UNzINCj4gDQo+IFdlIGFyZSBsb29raW5nIGZvciBh IG1pbnV0ZSB0YWtlciBhbmQgamFiYmVyIHNjcmliZS4NCj4gDQo+IFNwZWFrZXJzIHBsZWFzZSBz ZW5kIHVzIGEgUERGIG9mIHlvdXIgc2xpZGVzIGJ5IE1vbmRheSA0IE1heSAyMDIwIDE3OjAwIFVU Qy4NCj4gDQo+IEJvYiAmIE9sZQ0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3 b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0 aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gDQo+IA0KPg== --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjFweDsiPkhpJm5ic3A7Qm9i 77yMPC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7 Ij4mbmJzcDtUaGFuayB5b3UgaW4gYWR2YW5jZe+8gTwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0 cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtm b250LWZhbWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMjFweDsiPiZuYnNw O1JlZ2FyZHMsPC9zcGFuPjxiciBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsiPjxzcGFuIHN0 eWxlPSJsaW5lLWhlaWdodDogMjFweDsiPiZuYnNwO1lBTzwvc3Bhbj48L3A+PHAgc3R5bGU9ImZv bnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1z aXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxkaXY+PGRpdiBjbGFzcz0iemhp c3RvcnlSb3ciIHN0eWxlPSJkaXNwbGF5OmJsb2NrIj48ZGl2IGNsYXNzPSJ6aGlzdG9yeURlcyIg c3R5bGU9IndpZHRoOiAxMDAlOyBoZWlnaHQ6IDI4cHg7IGxpbmUtaGVpZ2h0OiAyOHB4OyBiYWNr Z3JvdW5kLWNvbG9yOiAjRTBFNUU5OyBjb2xvcjogIzEzODhGRjsgdGV4dC1hbGlnbjogY2VudGVy OyIgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeU9yZ1R4dCI+5Y6f5aeL6YKu5Lu2PC9kaXY+PGRpdiBp ZD0iendyaXRlSGlzdG9yeUNvbnRhaW5lciI+PGRpdiBjbGFzcz0iY29udHJvbC1ncm91cCB6aGlz dG9yeVBhbmVsIj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUhlYWRlciIgc3R5bGU9InBhZGRpbmc6IDhw eDsgYmFja2dyb3VuZC1jb2xvcjogI0Y1RjZGODsiPjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRh PSJIaXN0b3J5U2VuZGVyVHh0Ij7lj5Hku7bkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJl YWRVc2VyTmFtZSI+Qm9iSGluZGVuICZsdDtib2IuaGluZGVuQGdtYWlsLmNvbSZndDs8L3NwYW4+ PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlUT1R4dCI+5pS25Lu25Lq6 77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBp bmxpbmU7Ij7liJjlsKcwMDE2NTI4Njs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdl LWRhdGE9Ikhpc3RvcnlDQ1R4dCI+5oqE6YCB5Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9Inpy ZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5Cb2IgSGluZGVuICZsdDtib2Iu aGluZGVuQGdtYWlsLmNvbSZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBz dHlsZT0iZGlzcGxheTogaW5saW5lOyI+T2xlIFRyw7hhbiAmbHQ7b3Ryb2FuQGVtcGxveWVlcy5v cmcmZ3Q7Ozwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6 IGlubGluZTsiPklQdjYgTGlzdCAmbHQ7aXB2NkBpZXRmLm9yZyZndDs7PC9zcGFuPjwvZGl2Pjxk aXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5RGF0ZVR4dCI+5pelIOacnyDvvJo8L3N0 cm9uZz48c3BhbiBjbGFzcz0iIj4yMDIw5bm0MDXmnIgwN+aXpSAxMTowNjwvc3Bhbj48L2Rpdj48 ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVN1YmplY3RUeHQiPuS4uyDpopgg77ya PC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVGl0bGUiPjxzdHJvbmc+UmU6IEFnZW5kYSBmb3Ig Nm1hbiBJbnRlcmltIG1lZXRpbmcgJm5ic3A7b24gNSBNYXkgMjAyMDwvc3Ryb25nPjwvc3Bhbj48 L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUNvbnRlbnQiPjxkaXY+WWFvLDxicj48YnI+ SSZuYnNwO3dpbGwmbmJzcDtzZWUmbmJzcDt3aGF0Jm5ic3A7SSZuYnNwO2NhbiZuYnNwO2ZpbmQm bmJzcDtvdXQmbmJzcDthbmQmbmJzcDtiZSZuYnNwO2JhY2smbmJzcDtpbiZuYnNwO3RvdWNoLjxi cj48YnI+Qm9iPGJyPjxicj48YnI+Jmd0OyZuYnNwO09uJm5ic3A7TWF5Jm5ic3A7NiwmbmJzcDsy MDIwLCZuYnNwO2F0Jm5ic3A7NjoyNyZuYnNwO1BNLCZuYnNwO2xpdS55YW83MUB6dGUuY29tLmNu Jm5ic3A7d3JvdGU6PGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwO0hpJm5ic3A7Qm9iJm5ic3A7 JmFtcDsmbmJzcDtPbGUsPGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwO0kmbmJzcDt3b25kZXIm bmJzcDsmbmJzcDtpZiZuYnNwO3RoZXJlJm5ic3A7aXMmbmJzcDthJm5ic3A7bGluayZuYnNwO2Zv ciZuYnNwO2F1ZGlvJm5ic3A7cmVjb3JkaW5nJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7bWVldGlu ZywmbmJzcDtzaW5jZSZuYnNwO0kmbmJzcDtjYW5ub3QmbmJzcDtmaW5kJm5ic3A7aXQmbmJzcDtp biZuYnNwO2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvNm1hbi9tZWV0aW5ncy88YnI+ Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7VGhhbmtzJm5ic3A7YSZuYnNwO2xvdCZuYnNwOyE8YnI+ Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7PGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwO0Jlc3Qm bmJzcDtSZWdhcmRzLDxicj4mZ3Q7Jm5ic3A7PGJyPiZndDsmbmJzcDtZQU88YnI+Jmd0OyZuYnNw Ozxicj4mZ3Q7Jm5ic3A7PGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7 PGJyPiZndDsmbmJzcDvljp/lp4vpgq7ku7Y8YnI+Jmd0OyZuYnNwO+WPkeS7tuS6uu+8mkJvYkhp bmRlbiZuYnNwOyZsdDtib2IuaGluZGVuQGdtYWlsLmNvbSZndDs8YnI+Jmd0OyZuYnNwO+aUtuS7 tuS6uu+8mklQdjYmbmJzcDtMaXN0Jm5ic3A7Jmx0O2lwdjZAaWV0Zi5vcmcmZ3Q7Ozxicj4mZ3Q7 Jm5ic3A75oqE6YCB5Lq677yaQm9iJm5ic3A7SGluZGVuJm5ic3A7Jmx0O2JvYi5oaW5kZW5AZ21h aWwuY29tJmd0Ozs8YnI+Jmd0OyZuYnNwO+aXpSZuYnNwO+acnyZuYnNwO++8mjIwMjDlubQwNeac iDAx5pelJm5ic3A7MDQ6NTQ8YnI+Jmd0OyZuYnNwO+S4uyZuYnNwO+mimCZuYnNwO++8mkFnZW5k YSZuYnNwO2ZvciZuYnNwOzZtYW4mbmJzcDtJbnRlcmltJm5ic3A7bWVldGluZyZuYnNwOyZuYnNw O29uJm5ic3A7NSZuYnNwO01heSZuYnNwOzIwMjA8YnI+Jmd0OyZuYnNwO1RoZSZuYnNwO2FnZW5k YSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO21lZXRpbmcmbmJzcDtjYW4mbmJzcDtiZSZuYnNwO2Zv dW5kJm5ic3A7YXQ6PGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjAtNm1hbi0wMi9tYXRl cmlhbHMvYWdlbmRhLWludGVyaW0tMjAyMC02bWFuLTAyLTZtYW4tMDEuaHRtbDxicj4mZ3Q7Jm5i c3A7PGJyPiZndDsmbmJzcDtUaW1lOiZuYnNwOyZuYnNwOzE1OjAwJm5ic3A7LSZuYnNwOzE2OjU5 Jm5ic3A7UERULCZuYnNwOzUmbmJzcDtNYXkmbmJzcDsyMDIwJm5ic3A7LyZuYnNwOzIyOjAwJm5i c3A7LSZuYnNwOzIzOjU5Jm5ic3A7VVRDLCZuYnNwOzUmbmJzcDtNYXkmbmJzcDsyMDIwPGJyPiZn dDsmbmJzcDs8YnI+Jmd0OyZuYnNwO1dlYmV4Jm5ic3A7aW5mbzo8YnI+Jmd0OyZuYnNwOzxicj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01U SUQ9bWZiNDcyODI1NDUwMzVhMzJlNjg5NDAwMGZjMWZlOWFlPGJyPiZndDsmbmJzcDsmbmJzcDsm bmJzcDtNZWV0aW5nJm5ic3A7bnVtYmVyJm5ic3A7KGFjY2VzcyZuYnNwO2NvZGUpOiZuYnNwOzYx NCZuYnNwOzA3NSZuYnNwOzE2ODxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7TWVldGluZyZuYnNw O3Bhc3N3b3JkOiZuYnNwOzd5VGpydGJuVDcyPGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwO1dl Jm5ic3A7YXJlJm5ic3A7bG9va2luZyZuYnNwO2ZvciZuYnNwO2EmbmJzcDttaW51dGUmbmJzcDt0 YWtlciZuYnNwO2FuZCZuYnNwO2phYmJlciZuYnNwO3NjcmliZS48YnI+Jmd0OyZuYnNwOzxicj4m Z3Q7Jm5ic3A7U3BlYWtlcnMmbmJzcDtwbGVhc2UmbmJzcDtzZW5kJm5ic3A7dXMmbmJzcDthJm5i c3A7UERGJm5ic3A7b2YmbmJzcDt5b3VyJm5ic3A7c2xpZGVzJm5ic3A7YnkmbmJzcDtNb25kYXkm bmJzcDs0Jm5ic3A7TWF5Jm5ic3A7MjAyMCZuYnNwOzE3OjAwJm5ic3A7VVRDLjxicj4mZ3Q7Jm5i c3A7PGJyPiZndDsmbmJzcDtCb2ImbmJzcDsmYW1wOyZuYnNwO09sZTxicj4mZ3Q7Jm5ic3A7PGJy PiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsmbmJzcDtJRVRGJm5i c3A7SVB2NiZuYnNwO3dvcmtpbmcmbmJzcDtncm91cCZuYnNwO21haWxpbmcmbmJzcDtsaXN0PGJy PiZndDsmbmJzcDtpcHY2QGlldGYub3JnPGJyPiZndDsmbmJzcDtBZG1pbmlzdHJhdGl2ZSZuYnNw O1JlcXVlc3RzOiZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2 Njxicj4mZ3Q7Jm5ic3A7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7PGJy PiZndDsmbmJzcDs8YnI+PGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjxw Pjxicj48L3A+PC9kaXY+ --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Thu May 7 09:44:34 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EA63A0B91 for ; Thu, 7 May 2020 09:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=E/6h8F1u; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FtBmyKOJ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-UK2KCHQp8e for ; Thu, 7 May 2020 09:44:29 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95EC3A0B72 for <6man@ietf.org>; Thu, 7 May 2020 09:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27129; q=dns/txt; s=iport; t=1588869868; x=1590079468; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qcm7+T3VcxDQx1Ag/28/efyhuoxVh5XamzJgliF6jeI=; b=E/6h8F1uSl0iLnt+Ajwh85909NImkKgI3uCrukml9ThU+bVPZuT1y962 2jiOLCDKrRc80+UZraEssokTEWbypV6/qh+7JJbsLbOIuJMyfo+BYY6NR 2mVEST49pTiunxia810lf+Eql+E12ufkvHlQjVHf8kp1LcTnr6AzSwotD M=; IronPort-PHdr: =?us-ascii?q?9a23=3ArfQLmBK6Xh3KPJoMTdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKk/g1rAXIGd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkdQEcf6IVbVpy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuCQD2ObRe/4kNJK1mHQEBAQEJARI?= =?us-ascii?q?BBQUBggeBJS9RBW4OSi8qCoQZg0YDjR0liXmOPIFCgRADVAsBAQEMAQEYAQw?= =?us-ascii?q?IAgQBAYN/RQIXgXAkOBMCAwEBCwEBBQEBAQIBBQRthVYMhXEBAQEBAQIBARA?= =?us-ascii?q?RHQEBLAsBDwIBCA4DAwECIQcDAgICHwYLFAkIAgQOBSKDBAGBfk0DLgEOpTc?= =?us-ascii?q?CgTmIYXaBMoMAAQEFgTIBg3gNC4IOCYE4gmOJYRqBQT+BOAwQgk0+gh5JAQE?= =?us-ascii?q?BAYEuARIBICENCYJcM4ItjkKDB4YamihKCoJIiBiLNIRKHZ0gmWuCRo0+g0Q?= =?us-ascii?q?CBAIEBQIOAQEFgWkiZnBwFTsqAYI+CTUSGA2QQoJUgR4zhGGFQnQCBTACBgE?= =?us-ascii?q?HAQEDCXyQOgGBDwEB?= X-IronPort-AV: E=Sophos;i="5.73,364,1583193600"; d="scan'208,217";a="502209954" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2020 16:44:28 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 047GiRIM029528 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 May 2020 16:44:28 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 May 2020 11:44:27 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 May 2020 11:44:27 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 7 May 2020 12:44:27 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=maeCNlRdygroc6l/9wEXZUv9rVF0VYPALoss0NYhRMUhGVlqRwLZFhTC2xPcfy+8lgDWJhWqT+uMWFB6MZZz6YaA1ZLniKdEZoMfrOoBbU+u4VSiU3nwb5sSMvblTjEz2z2RXYitFTCUChPvPiuj41AWWFrujEMj73qgbAM9x7rTm/tSb03GUpO/osQdjRw6GdvzfXHvLyQHXv+VqClEsYeOKAfDdk+AIxbKjtCFu7e10A9LfvxV5jVem9XVKbMVXCQEEpRa0AgEnj+a9vf4oFpc9tWEs0zCwE+34yyXY9RmoKYASABHciSSk9sJ3ZhqdDkR1jAyOtfkkra09gDStQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qcm7+T3VcxDQx1Ag/28/efyhuoxVh5XamzJgliF6jeI=; b=Q3veecoqeOFvQj82IQjqTh3CXRuE9sSZtouS0rXoNhSbjSyN5IphAX6GFB3yk/ItDG7m0hW0VCksSbhzPVulBkroifR3kvqAOIKyCC+B3cTFVclq9W3rzxjdg9hlpuIr+rA2nw4NBOGmgfit/1mVnTbCju7F6uCoDOOIVL0Ir6nfuZ++dE+9x7Tqem98h9nlOrHA+9dManTCuJFC7zgEXkXTV22Z+G9JutlxSX4AoVLuDQotLyYrtLpMKge/GSIoEkHTKczNBDIkAHe/O2fhYujoTeAx8FxVW1y57Rrj3jbH3/5KMdjykboqD1KsadVmfY8HCn7Apq+2O2KU/Ldvxw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qcm7+T3VcxDQx1Ag/28/efyhuoxVh5XamzJgliF6jeI=; b=FtBmyKOJjp/MSD4Ur4h7puGy4M/1KeOM49tiq+hTzLQSWNDKXsBhhqZv9W8xYWHguAifgFLw04OCv3d74wvuiVPZxLnJkisML8rTvWIq+kMPYWV7SghY5ukZolCGgKhsqOPwDFzCe3FqdFLQBJCv6q4XcTr99HLdB4KvoWjgNBo= Received: from DM5PR11MB1818.namprd11.prod.outlook.com (2603:10b6:3:114::9) by DM5PR11MB1817.namprd11.prod.outlook.com (2603:10b6:3:10e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Thu, 7 May 2020 16:44:26 +0000 Received: from DM5PR11MB1818.namprd11.prod.outlook.com ([fe80::c65:7b5f:228a:edc3]) by DM5PR11MB1818.namprd11.prod.outlook.com ([fe80::c65:7b5f:228a:edc3%12]) with mapi id 15.20.2958.033; Thu, 7 May 2020 16:44:26 +0000 From: "Darren Dukes (ddukes)" To: Krzysztof Szarkowicz CC: "Voyer, Daniel" , Ron Bonica , "Eric Vyncke (evyncke)" , 6man <6man@ietf.org> Subject: Re: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AQHWI58t0MrEgFbBRG+Eev5I1WHYlaia/q4AgAHXnIA= Date: Thu, 7 May 2020 16:44:26 +0000 Message-ID: <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> In-Reply-To: <497430AB-1840-4320-991F-B4906607033E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.14) authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [198.84.207.201] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 21517ce4-0014-43df-b3ac-08d7f2a5e76c x-ms-traffictypediagnostic: DM5PR11MB1817: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UZw0jJ+CE6BpTwHkDHjYY+f/cAYm/3520mg5L3dwjrGQ8TIy4CX+paTiiDwRWjDD01SHA3itpALSVpZL2HXN3Jzj1KRKOJq6MRR1FhdZJGQUuFrHnVP1s6ZTpnww8MGSLSBAYIjakTFrM90Cy6VpaHRlYVvfDfxH6Ffy5C0il72SHHsO65gWFbdzS6ZSnJxMFXT2tz3AHEqeMEsSGbk3sKTx5e//W7eqzLhn5BWsO44U1MVuhgQVFdgPrawofdjOJQXOKqW0MATB5OvSo/UtO/Nd7ejGPkOqHbPgV6ME5rl6oK8j68t5BWPJXhSj541NngZQO4EUuz+m6lKiWGKYK6nblAS0+Ayv+roVOHGNd7UdqesETPkLxVaqRfXO6yObqxbPLy2tgQypDwVKB2FrBffcI3D8Dp0uuM+G2HZ2LW4n1/yAEq+uZ7mqP2nb/LSGYNTuJuQcgU7shsRDpeyJsohUIxHB63It7t436mYxK6N7B1estTGHlRcsy8kNYfXJTnpZT3Gl620RNSh6U7NPl6oVIbk3zSoQCBcmkIWlir/Srn6R9K2kCkYYy4o/PtE8VavQqjYNApMHhQQdFovejgYwmGynQ7xriUeKrg/XEoM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1818.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(346002)(136003)(39860400002)(366004)(33430700001)(7116003)(83320400001)(83310400001)(83300400001)(2616005)(83290400001)(83280400001)(26005)(54906003)(316002)(6506007)(478600001)(53546011)(966005)(6916009)(91956017)(66556008)(66476007)(6486002)(36756003)(66946007)(8676002)(5660300002)(76116006)(33440700001)(166002)(186003)(2906002)(86362001)(6512007)(8936002)(66446008)(33656002)(71200400001)(64756008)(3480700007)(4326008)(83080400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: n7+LEvRTbkPVtfqNPiyQnTZtXIOEhfFPApFKfSb34BuIZoqC4kt4vhA3LbHjw/rSrzENXvqwzlOMPLHWMGlf1hnETPmCd54UE4it1SaiJx3TMCyXRaB/czXeOiexROEo89aH/3ZmIEnTzy12FYt0QnXWZlo+AFxAVhqp8KolgwJj3pC2HFKbvre+a188utUBopCPS+kEwyXuP6D6M5Lk/oYWzhaGvKnbryxYe7yVHpseiiSIPnJtQpiyR3jREWx/OQTRft3C2riPxUrkIYQRWQtxfpm53mxuCNniBJJkTOojKd5m1NdShiF/wRc7Blr+lmxwU3X4qV333GR0IxgvQHqKoZjip6imrmTtUu4ucVfv89gE2w58hvBiv6OAjQqHijAby3HdfOmReJuLjea/zDgUzPIQCwsJu0Itek1czmX9BlN4S+rpgp5i954HPlJJ+rf1ttcw/IsSKfTkfkSA7NbZD3YzbIgCD4cLplBhVR0+rC1dfKmCaCGjJbfKXNzrTBqWFZY2c1wHytFJzX+qbwuZ4uHa2mxQm5ra7/n5VoyPR0f50nDb8TPhWWTHbOWp8T+8jKkaVfuSF/OClQov1Tsl65URdQcgivnJFxPEwGzwrBVYPLqJNfy1sg1V6e1aMBmOV4YKXAyUrOkK6bQ0BNPQqBPNaPqGp7yEAgnTp7JbrvvVjX+OC9VicBBqrwheCTS1TRn0r6GF8WSP6T8A/aLxpzQ5LTq95nhuh0u1rbelCPEthP9eLOOU4A6IhiEtbLJBzfpw0mRLaODDB/bJ0bi+X7fXFfQpbJBveKE48ic= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_6E089E7E4D094704A3A91A3878FC3786ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 21517ce4-0014-43df-b3ac-08d7f2a5e76c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 16:44:26.1711 (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: I/s09Uo52w+aS+Rnf5KLZnr8OGf7kxCmBlFP+UKNc5XHB9EHge8T7ySiA2+2u3jYNPJBbvCnLARPZXxopC6VNQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1817 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 16:44:32 -0000 --_000_6E089E7E4D094704A3A91A3878FC3786ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S3J6eXN6dG9mIHRoYW5rcyBmb3IgdGhlIGxpbmssIHRvIG1lIGl0IGRvZXMgc2VlbSB0aGF0IEp1 bmlwZXIgc2VlcyBTUkggaW5zZXJ0aW9uIGZvciBUSUxGQSBhcyBkZXNpcmFibGUsIGFzIGRvY3Vt ZW50ZWQgaW4gZHJhZnQtdm95ZXItNm1hbi1leHRlbnNpb24taGVhZGVyLWluc2VydGlvbi4NCg0K U28gRGFuLCBJIHRoaW5rIHdlIGNhbiBqdW1wIHRvIHRoYXQgY29uY2x1c2lvbiBzdXBwb3J0ZWQg YnkgMTkgaW1wbGVtZW50YXRpb25zIGFuZCA1IGRlcGxveW1lbnRzIGFzIGNhcHR1cmVkIGluIGRy YWZ0LW1hdHN1c2hpbWEtc3ByaW5nLXNydjYtZGVwbG95bWVudC1zdGF0dXMsIGluY2x1ZGluZyBK dW5pcGVyJ3MuDQoNCkRhcnJlbg0KDQoNCk9uIE1heSA2LCAyMDIwLCBhdCA4OjM2IEFNLCBLcnp5 c3p0b2YgU3phcmtvd2ljeiA8a3N6YXJrb3dpY3pAZ21haWwuY29tPG1haWx0bzprc3phcmtvd2lj ekBnbWFpbC5jb20+PiB3cm90ZToNCg0KQWxzbywNCg0KVGhlcmUgaXMgc2hvcnQgdmlkZW8gZGlz Y3Vzc2luZyBTUnY2IFRJLUxGQSBFQU5UQyB0ZXN0Og0KDQpodHRwczovL3lvdXR1LmJlL3Y5d29L LTdBaXlBDQoNClRoYW5rcywNCktyenlzenRvZg0KDQpPbiAyMDIwIC1NYXktMDYsIGF0IDE0OjA5 LCBWb3llciwgRGFuaWVsIDxkYW5pZWwudm95ZXJAYmVsbC5jYTxtYWlsdG86ZGFuaWVsLnZveWVy QGJlbGwuY2E+PiB3cm90ZToNCg0KUm9uLCB5ZXMg4oCTIEkgZWNobyBFcmljIOKAkyBhbGwgbXkg cmVzcGVjdC4NCg0KUm9uLCBJIGZvciBvbmUsIHdvdWxkIGp1bXAgdG8gY29uY2x1c2lvbiBmb3Ig dGhhdCBzcGVjaWZpYyB1c2UgY2FzZSB3aGVyZSBpbnNlcnRpb24gaXMgcGVyZm9ybWVkLCBhbmQg aGF2ZSB0aGUgZXhwZWN0ZWQgYmVoYXZpb3VyLiBUaGlzIGlzIHRoZSBleGFjdCB1c2UgY2FzZSB0 aGF0IHdhcyBkZXNjcmliZWQgb3ZlciB0aGUgeWVhcnMgaW4gdGhpcyBtYWlsaW5nIGxpc3QsDQoN Ck5vdywgb2J2aW91c2x5LCB0aGlzIHVzZSBjYXNlIGlzIGNvbnRhaW4gd2l0aGluIHRoZSBvcGVy YXRvciBkb21haW4uIEkgZG9u4oCZdCBleHBlY3QgYW4gb3BlcmF0b3IgdG8gaGF2ZSDigJxUSS1M RkHigJ0gb24gdGhlaXIgcGVlcmluZyBsaW5rcyB3aXRoIG90aGVyIHRyYW5zaXQvb3BlcmF0b3Iu DQoNCkZvciBwZW9wbGUgcmVmZXJlbmNlcywgcGFnZSAxNSDigJxUSS1MRkEgb3ZlciBTUnY24oCd Og0KaHR0cDovL3d3dy5lYW50Yy5kZS9maWxlYWRtaW4vZWFudGMvZG93bmxvYWRzL2V2ZW50cy9N UExTMjAyMC9FQU5UQy1NUExTU0ROTkZWMjAyMC1XaGl0ZVBhcGVyLnBkZg0KDQpUaGFua3MsDQpk YW4NCg0KRnJvbTogaXB2NiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppcHY2LWJvdW5j ZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgIkVyaWMgVnluY2tlIChldnluY2tlKSIgPGV2eW5j a2U9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmV2eW5ja2U9NDBjaXNjby5jb21A ZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogV2VkbmVzZGF5LCBNYXkgNiwgMjAyMCBhdCA3OjA4IEFN DQpUbzogUm9uIEJvbmljYSA8cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPG1h aWx0bzpyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+PiwgNm1hbiA8Nm1hbkBp ZXRmLm9yZzxtYWlsdG86Nm1hbkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbRVhUXVJlOiBSb3V0aW5n IEhlYWRlciBJbnNlcnRpb24NCg0KUm9uLA0KDQpBbGwgbXkgcmVzcGVjdCB0byB5b3UgZm9yIHRo aXMgY29ycmVjdGlvbiBvZiB5b3Vycy4NCg0KUmVnYXJkcw0KDQotw6lyaWMNCg0KUFM6IEkgd2Fz IGFib3V0IHRvIHJlcGx5IHVuaWNhc3QgdG8gUm9uIGJ1dCBkZWNpZGVkIHRoYXQgUm9uIGRlc2Vy dmVzIHNvbWUgcHVibGljIGFwcHJlY2lhdGlvbiBmb3IgaGlzIGVtYWlsLg0KDQpGcm9tOiBpcHY2 IDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZz4+IG9u IGJlaGFsZiBvZiBSb24gQm9uaWNhIDxyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5v cmc8bWFpbHRvOnJib25pY2E9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBX ZWRuZXNkYXksIDYgTWF5IDIwMjAgYXQgMDI6NTINClRvOiA2bWFuIDw2bWFuQGlldGYub3JnPG1h aWx0bzo2bWFuQGlldGYub3JnPj4NClN1YmplY3Q6IFJvdXRpbmcgSGVhZGVyIEluc2VydGlvbg0K DQpGb2xrcywNCg0KTXkgYXBvbG9naWVzIHRvIFphZmFyIEFsaS4gUmVhZGluZyB0aHJvdWdoIHRo ZSBFQU5UQyByZXBvcnQsIGl0IGFwcGVhcnMgdGhlIEp1bmlwZXIgZGVtb25zdHJhdGlvbiBTUnY2 IFJvdXRpbmcgSGVhZGVyIGluc2VydGlvbiB0byBzdXBwb3J0IFRJLUxGQS4gSW4gdGhhdCByZXNw ZWN0LCBaYWZhciBpcyBjb3JyZWN0Lg0KDQpIb3dldmVyLCB3ZSBzaG91bGQgbm90IGp1bXAgdG8g dGhlIGNvbmNsdXNpb24gdGhhdCBzdWNoIGJlaGF2aW9yIGlzIGRlc2lyYWJsZS4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBSb24NCg0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCg0KDQoNCkp1bmlw ZXIgQnVzaW5lc3MgVXNlIE9ubHkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdy b3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkFk bWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBn cm91cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpB ZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= --_000_6E089E7E4D094704A3A91A3878FC3786ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5B6B995619AF6545948455E0F90B4F19@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCktyenlzenRvZiB0aGFua3MgZm9yIHRoZSBsaW5r LCB0byBtZSBpdCBkb2VzIHNlZW0gdGhhdCBKdW5pcGVyIHNlZXMgU1JIIGluc2VydGlvbiBmb3Ig VElMRkEgYXMgZGVzaXJhYmxlLCBhcyBkb2N1bWVudGVkIGluIGRyYWZ0LXZveWVyLTZtYW4tZXh0 ZW5zaW9uLWhlYWRlci1pbnNlcnRpb24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU28g RGFuLCBJIHRoaW5rIHdlIGNhbiBqdW1wIHRvIHRoYXQgY29uY2x1c2lvbiBzdXBwb3J0ZWQgYnkm bmJzcDsxOSBpbXBsZW1lbnRhdGlvbnMgYW5kIDUgZGVwbG95bWVudHMgYXMgY2FwdHVyZWQgaW4m bmJzcDtkcmFmdC1tYXRzdXNoaW1hLXNwcmluZy1zcnY2LWRlcGxveW1lbnQtc3RhdHVzLCBpbmNs dWRpbmcgSnVuaXBlcidzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkRhcnJlbjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1heSA2LCAyMDIwLCBhdCA4 OjM2IEFNLCBLcnp5c3p0b2YgU3phcmtvd2ljeiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtzemFya293 aWN6QGdtYWlsLmNvbSIgY2xhc3M9IiI+a3N6YXJrb3dpY3pAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0K QWxzbywNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlRoZXJlIGlzIHNob3J0IHZpZGVvIGRpc2N1c3NpbmcgU1J2NiBUSS1MRkEgRUFOVEMgdGVzdDo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxhIGhyZWY9Imh0dHBzOi8veW91dHUuYmUvdjl3b0stN0FpeUEiIGNsYXNzPSIiPmh0dHBzOi8v eW91dHUuYmUvdjl3b0stN0FpeUE8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkty enlzenRvZjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDIw MjAgLU1heS0wNiwgYXQgMTQ6MDksIFZveWVyLCBEYW5pZWwgJmx0OzxhIGhyZWY9Im1haWx0bzpk YW5pZWwudm95ZXJAYmVsbC5jYSIgY2xhc3M9IiI+ZGFuaWVsLnZveWVyQGJlbGwuY2E8L2E+Jmd0 OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29y ZFNlY3Rpb24xOyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KUm9uLCB5ZXMg4oCTIEkgZWNobyBFcmljIOKA kyBhbGwgbXkgcmVzcGVjdC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpSb24s IEkgZm9yIG9uZSwgd291bGQganVtcCB0byBjb25jbHVzaW9uIGZvciB0aGF0IHNwZWNpZmljIHVz ZSBjYXNlIHdoZXJlIGluc2VydGlvbiBpcyBwZXJmb3JtZWQsIGFuZCBoYXZlIHRoZSBleHBlY3Rl ZCBiZWhhdmlvdXIuIFRoaXMgaXMgdGhlIGV4YWN0IHVzZSBjYXNlIHRoYXQgd2FzIGRlc2NyaWJl ZCBvdmVyIHRoZSB5ZWFycyBpbiB0aGlzIG1haWxpbmcgbGlzdCw8bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpw IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQpOb3csIG9idmlvdXNseSwgdGhpcyB1c2UgY2FzZSBpcyBjb250YWlu IHdpdGhpbiB0aGUgb3BlcmF0b3IgZG9tYWluLiBJIGRvbuKAmXQgZXhwZWN0IGFuIG9wZXJhdG9y IHRvIGhhdmUg4oCcVEktTEZB4oCdIG9uIHRoZWlyIHBlZXJpbmcgbGlua3Mgd2l0aCBvdGhlciB0 cmFuc2l0L29wZXJhdG9yLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkZvciBw ZW9wbGUgcmVmZXJlbmNlcywgcGFnZSAxNSDigJxUSS1MRkEgb3ZlciBTUnY24oCdOjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuZWFudGMuZGUvZmlsZWFkbWluL2VhbnRjL2Rvd25s b2Fkcy9ldmVudHMvTVBMUzIwMjAvRUFOVEMtTVBMU1NETk5GVjIwMjAtV2hpdGVQYXBlci5wZGYi IHN0eWxlPSJjb2xvcjogcmdiKDUsIDk5LCAxOTMpOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsiIGNsYXNzPSIiPmh0dHA6Ly93d3cuZWFudGMuZGUvZmlsZWFkbWluL2VhbnRjL2Rvd25sb2Fk cy9ldmVudHMvTVBMUzIwMjAvRUFOVEMtTVBMU1NETk5GVjIwMjAtV2hpdGVQYXBlci5wZGY8L2E+ PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KVGhhbmtzLDxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CmRhbjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC13aWR0aDog MXB0OyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IHBhZGRpbmc6IDNwdCAw Y20gMGNtOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0i Ij5Gcm9tOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5pcHY2ICZs dDs8YSBocmVmPSJtYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHJn Yig1LCA5OSwgMTkzKTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5pcHY2 LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KIG9uIGJlaGFsZiBvZiAmcXVvdDtFcmljIFZ5bmNr ZSAoZXZ5bmNrZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpldnluY2tlPTQwY2lzY28uY29t QGRtYXJjLmlldGYub3JnIiBzdHlsZT0iY29sb3I6IHJnYig1LCA5OSwgMTkzKTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5ldnluY2tlPTQwY2lzY28uY29tQGRtYXJjLmll dGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5EYXRlOjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+V2VkbmVzZGF5LCBNYXkg NiwgMjAyMCBhdCA3OjA4IEFNPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Sb24gQm9uaWNhICZs dDs8YSBocmVmPSJtYWlsdG86cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnIiBz dHlsZT0iY29sb3I6IHJnYig1LCA5OSwgMTkzKTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 IiBjbGFzcz0iIj5yYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Oywg Nm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOjZtYW5AaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcmdi KDUsIDk5LCAxOTMpOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjZtYW5A aWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5bRVhUXVJlOiBS b3V0aW5nIEhlYWRlciBJbnNlcnRpb248bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJGUiIg Y2xhc3M9IiI+Um9uLDwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJGUiIgY2xhc3M9 IiI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0i Ij5BbGwgbXkgcmVzcGVjdCB0byB5b3UgZm9yIHRoaXMgY29ycmVjdGlvbiBvZiB5b3Vycy48L3Nw YW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPiZuYnNwOzwvc3Bh bj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+UmVnYXJkczwvc3Bh bj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFu PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj4tw6lyaWM8L3NwYW4+ PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+UFM6IEkgd2FzIGFib3V0 IHRvIHJlcGx5IHVuaWNhc3QgdG8gUm9uIGJ1dCBkZWNpZGVkIHRoYXQgUm9uIGRlc2VydmVzIHNv bWUgcHVibGljIGFwcHJlY2lhdGlvbiBmb3IgaGlzIGVtYWlsLjwvc3Bhbj48bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0 eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3Atd2lkdGg6IDFwdDsgYm9yZGVyLXRvcC1j b2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBwYWRkaW5nOiAzcHQgMGNtIDBjbTsiIGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0IDM2cHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5Gcm9tOjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5pcHY2ICZsdDs8YSBocmVmPSJt YWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHJnYig1LCA5OSwgMTkz KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5pcHY2LWJvdW5jZXNAaWV0 Zi5vcmc8L2E+Jmd0Ow0KIG9uIGJlaGFsZiBvZiBSb24gQm9uaWNhICZsdDs8YSBocmVmPSJtYWls dG86cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnIiBzdHlsZT0iY29sb3I6IHJn Yig1LCA5OSwgMTkzKTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5yYm9u aWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPkRhdGU6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj5XZWRuZXNkYXksIDYgTWF5IDIwMjAgYXQgMDI6NTI8YnIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj5Ubzo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9iPjZtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzo2bWFuQGlldGYub3JnIiBzdHlsZT0i Y29sb3I6IHJnYig1LCA5OSwgMTkzKTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFz cz0iIj42bWFuQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJq ZWN0OjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+ Um91dGluZyBIZWFkZXIgSW5zZXJ0aW9uPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQgMzZwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0IDM2cHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkZvbGtz LDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQgMzZwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdCAzNnB0OyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpNeSBhcG9sb2dp ZXMgdG8gWmFmYXIgQWxpLiBSZWFkaW5nIHRocm91Z2ggdGhlIEVBTlRDIHJlcG9ydCwgaXQgYXBw ZWFycyB0aGUgSnVuaXBlciBkZW1vbnN0cmF0aW9uIFNSdjYgUm91dGluZyBIZWFkZXIgaW5zZXJ0 aW9uIHRvIHN1cHBvcnQgVEktTEZBLiBJbiB0aGF0IHJlc3BlY3QsIFphZmFyIGlzIGNvcnJlY3Qu PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdCAzNnB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0IDM2cHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkhvd2V2ZXIsIHdl IHNob3VsZCBub3QganVtcCB0byB0aGUgY29uY2x1c2lvbiB0aGF0IHN1Y2ggYmVoYXZpb3IgaXMg ZGVzaXJhYmxlLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQgMzZwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdCAzNnB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgUm9uPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdCAzNnB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 IDM2cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8cCBjbGFzcz0i bXNpcGZvb3RlcjMwYjNkNTM4IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAw Y207IG1hcmdpbi1sZWZ0OiAzNnB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgdGV4dC1hbGlnbjogY2Vu dGVyOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA3cHQ7IiBjbGFzcz0iIj5KdW5pcGVyIEJ1 c2luZXNzIFVzZSBPbmx5PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0IDM2cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8cCBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiA1 cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgbWFyZ2luLWxlZnQ6IDQxcHQ7IHRleHQtYWxpZ246IGNl bnRlcjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogN3B0OyIgY2xhc3M9IiI+ SnVuaXBlciBCdXNpbmVzcyBVc2UgT25seTwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPklFVEYNCiBJUHY2IHdvcmtpbmcg Z3JvdXAgbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgc3R5bGU9 ImNvbG9yOiByZ2IoNSwgOTksIDE5Myk7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmlwdjZAaWV0Zi5v cmc8L2E+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkFkbWluaXN0cmF0aXZlDQogUmVx dWVzdHM6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYi IHN0eWxlPSJjb2xvcjogcmdiKDUsIDk5LCAxOTMpOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y dGFudDsiIGNsYXNzPSIiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xh c3M9IiI+DQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgY2xhc3M9IiI+aXB2NkBpZXRmLm9yZzwv YT48YnIgY2xhc3M9IiI+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_6E089E7E4D094704A3A91A3878FC3786ciscocom_-- From nobody Thu May 7 10:03:27 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D053A0BBA for ; Thu, 7 May 2020 10:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=juniper.net header.b=PS2wpoNC; dkim=pass (1024-bit key) header.d=juniper.net header.b=GqZFYM6k Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ba0g2CwkTXIc for ; Thu, 7 May 2020 10:03:20 -0700 (PDT) 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 354223A0BCC for <6man@ietf.org>; Thu, 7 May 2020 10:03:16 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 047H1u7s029840; Thu, 7 May 2020 10:03:13 -0700 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 : mime-version; s=PPS1017; bh=wlpMsl6ypPGBe3qlOcvXC43GBoy2lWbZ5eDhZtsNgVw=; b=PS2wpoNCxkc6d3VOXY3/u3pWpHDHpvwjslrXpA1cTYzODf/qc4q2Z1YUPo8fLELqprKW cM782YJxAP1JMK07cLIBP2D9ZyEg3Aymvy7cb9hzRLXFOyNUAahbqxG+ZxmMMo+nwn4v BCPQdA+XZkgXSvmU3uEndxMVSNEIWiDy8MYx0gRfLRf/ZrI9iMmdBzjBMdMgmWZg2MQo voRuw6YhOVVgnBIRGJFOrOzoYMWkiHLYMadtoxoKcXcYRo3uDqCrY2h9PLCZGpYSjz4R 0Es6DF953k2UYOSWHMaAZN7K3TmNmLytCaqoczTgy+pxVGtuK8BV9MiTO/hJu0JbUbk2 wA== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2177.outbound.protection.outlook.com [104.47.55.177]) by mx0b-00273201.pphosted.com with ESMTP id 30v17m254g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 May 2020 10:03:13 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bd7khhjnA6Ebfx9JXfLBxOpQVuXx/8zhGumynGzK73DCgXFY+5inLkvAXnAExEBWtFHIMJJK3SJAPHf5PyaJrrrprIG6WkuqWlzu8Pxshj3aoFnTZKrrwtGf0rsfzVz5bokNBo/FMVE16zm1+kBzVA0r/iOD+UIIIRPKnmm2AHh2TGJNW9nxLv70RsigU+eXmPtpRgrTuTe4OLHxaA4BpNFGI9vJppOZq7RxCw4HKc0pV0sYBmT9qtyoegC61Vb7U6mzrzsLXqx3avhYtgargAcfP/TJ5UqUm0JCziqk2XcB8Iq/BjpTW5Zhb+QSDIPlQE65Kfa4dHLWrkr7UIWi+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wlpMsl6ypPGBe3qlOcvXC43GBoy2lWbZ5eDhZtsNgVw=; b=f4XO0jjaJK2mS6mjUAMWnIiMqU8lRUDgKob+tZrAhWaSxi0Nw5clHON+IwlZbGfqixtUpfGxcUrrwJ5NvVD85EDspzspAlmi3FDMcxtu1mqVcm1NLFavYuM4q7g9i4vtoDnGOFu2JjA+6SdJO6vSoxsCzUWnCziGlmwwf0gRWAJnqq5Hkx/Cvl5tM+IlsKYIlWmRA6z978melc1kIQZ3FgnEXFbOdoMcM2TDS0lFXaibqAWr4+oXF+GcAN7U17NKjATCWSwdy+w4WQx5OjaU9oZU/wAdk39M9qv3m1XXElsEywTXJeearghqpeJBWHzWXqGbvvJ0KKAwdEM0keoKfg== 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=wlpMsl6ypPGBe3qlOcvXC43GBoy2lWbZ5eDhZtsNgVw=; b=GqZFYM6koEaQt3HzjT54AQNkrY52Az2cmWHNYhqStp2FA7Yny/THK2Lf4lP91ZqUbszSuxacSKKvjQNhVw5aJZinChLRiwBoHVcEBlAEBgYmchsosA2wtyYtL6Cn6bgUhTZ80pALY7KPvfZwnIP9bDlaNVuhAnTKMFlwNIOSl0M= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB6043.namprd05.prod.outlook.com (2603:10b6:5:119::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.14; Thu, 7 May 2020 17:03:11 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.2979.028; Thu, 7 May 2020 17:03:11 +0000 From: Ron Bonica To: "Voyer, Daniel" , "Eric Vyncke (evyncke)" , 6man <6man@ietf.org> Subject: RE: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AQHWI58t0MrEgFbBRG+Eev5I1WHYlaic0H/g Date: Thu, 7 May 2020 17:03:11 +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_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-05-07T17:03:08.8070626Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=fcfb3c23-d00b-42c2-966d-5833400afcd3; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action authentication-results: bell.ca; dkim=none (message not signed) header.d=none;bell.ca; dmarc=none action=none header.from=juniper.net; x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: dec5e509-574e-4fc4-04cc-08d7f2a88638 x-ms-traffictypediagnostic: DM6PR05MB6043: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gOFafOzNkh3UtwSl/bTG+kitEQDdoUFwSga3Mi/LlS0jKypApssWkqfZWEYT2QhiNh32qdtQzZ3T9JUpIhZUMYSEYTE7Fs/T4qEIpmPgz2XKSfqSpNyf597h9u438UjSqZNghkU5QxTUTGwjEL1G/7CI5w6DvU5RDKvVF1ABI815xWocfH6Pzi4BKqSHZcqNW7Mf4d35Q5ZLgPgSEFPEnOzwn/4779PVbyEaZcmmlesmPUD22rrr6UHxS5zNWfhTzw4rW1JIbSFkrBV3U582TSTsK6F/LTJGlK28CH/KBNkhmQzIezRNY+mn3owUdKD13YnsIIc/nkmjVe+gI3kzckDFtueHUoBI1euiWv0MBoFCJ5ZE8tjPab64BrY/WIImXncqHo7UbUgEfqC3/9YbqAGZYZquikOtxHIT9xkooFl5J3eWprkVfulxLh9JQLzO8AbBwDAUZ50ip/LeuvaA8GgI2lZFEp1g1Mm3Y8s0N+SGpMXLwgLP4wmfFR22YncHLIvOsmtY3aSo5no/GPhDGv5MZ08rt4G9s6sgvVSSUhqjghaSRS87tWHsNTdOQjj2hvtD9eOJ6//QjrOyKtZOj4kUkOWj0S0E4dkVr8Ih13E= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(366004)(39860400002)(396003)(33430700001)(8936002)(71200400001)(83080400001)(9326002)(52536014)(6506007)(53546011)(7696005)(83300400001)(76116006)(66556008)(83290400001)(2906002)(83310400001)(83280400001)(83320400001)(66446008)(26005)(64756008)(66476007)(66946007)(86362001)(110136005)(33440700001)(55016002)(966005)(8676002)(9686003)(33656002)(478600001)(166002)(316002)(5660300002)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: JL0g/S+z5dixMILpbbdSvbd/xsYSBBHtRnJqO77fO3IWqsrw8nURk6GnybFNxRq+unvTGOm2z6tvO9pSh2FnLFpNNi0c6SyyZWg04exv4r7EuTfzzxCnwNanEf7xHasTcfifn8CBoKobZUXY4n6a0Bpw5kOtL5C353BoLLBpDIdZ6KmwQhiiZZGvQB3HVBP7v1eNLFr7EdwtRaowgKHCb2VrTaD6TqVtQOcCtFxrkvQ6FXNuKGX2D+y6oWucUj0O9EF5IqLqabif5zG4UTR9ghPK+a+fJ9aBQIVXqMgD5ZQZ1FVZqk53zyrXg8OhEc4ELQSh6AuMvPik2WofsmyybXWqxpIVxxL3A/TIFtbQxeDG394Yx1M+CS3/Tvgm0MqJVy2ystTgFVKZt5wHxHnWhv/DIXNkKDcg2Mgc8IxmkHEPurN04lTdzrryC5o0oRp9mljafyeYFQP5NgE36ZrsR7dxA9NsQY//BRuaIdYdMKqhFBdIFMjb2wFdraRI1AiSuGnEA3Ww+EDdmuygAy5Vat4/ppEdSgG7B7klRJM5Wntj5ubiIF4JV1CfSRjTbYZDAWCqV7bWLCusKKdM/mHlv18TFWKdrU37b1mx6BCtN1CI//ij7eZAye4FkRnsvsi5Aq1TMYSkAVdfO/RLgSM4KTfIaG7nWGiLONlaxpcTpjnXNtpZg/HC5SNJP3JhjhHfCZ5eei0cZp+p27WTHJZ5SMDmv/wN6YysWNDlNL1kRPRCV5QE/ARkzZ9vupL7pqgFvXb/r2r0/9hX7rwSk/WDP8XJs81Dt0zRjEY+fVGU6BU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB6348B22D75A7015AC966981CAEA50DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: dec5e509-574e-4fc4-04cc-08d7f2a88638 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 17:03:11.5550 (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: ZL12eG5WK8GAjkA4nkW/HNayKUyXvJo0lxg+Zc9l0DaOXbJz1yfL0NaywqqAcTmL70SXRcHRrHzszwlpCNz58g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB6043 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-07_10:2020-05-07, 2020-05-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 spamscore=0 clxscore=1031 mlxlogscore=999 mlxscore=0 adultscore=0 lowpriorityscore=0 bulkscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005070138 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 17:03:25 -0000 --_000_DM6PR05MB6348B22D75A7015AC966981CAEA50DM6PR05MB6348namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Daniel, TI-LFA with SRH insertion poses problems in the following cases: * When the packet already contains an SRH * When the IPv6 Destination Address contains uSIDs In the first case, when the packet already contains an SRH, TI-LFA with SRH= insertion results in a single packet that contains two SRH's. No reading o= f RFC 8200 allows this. The second case is more complex. Assume that in your uSID strategy: * The uSID block identifier is 32 bits long * Each uSID is 16 bits long * The end-of-carrier marker is also 16 bits long In this case, you can fit 5 uSIDs in the IPv6 address. On the first segment, when the destination address still contains 5 uSIDs, = a PLR detects link failure and invokes TI-LFA procedures. The repair tunnel= contains 3 segments. If the PLR executes TI-LFA with insertion procedures,= what does the resulting IPv6 Destination address look like? What does the = SRH look like? Yes, the problem can be solved, but not without deep though and vigorous he= ad scratching. When a solution is that complex, it is probably beyond the c= apability of any operations staff. The above-mentioned problems could have been avoided if TI-LFA created its = repair tunnel by prepending an IPv6 header with its own SRH. = Ron Juniper Business Use Only From: Voyer, Daniel Sent: Wednesday, May 6, 2020 8:09 AM To: Eric Vyncke (evyncke) ; Ron Bonica ; 6man <6man@ietf.org> Subject: RE: Routing Header Insertion [External Email. Be cautious of content] Ron, yes - I echo Eric - all my respect. Ron, I for one, would jump to conclusion for that specific use case where i= nsertion is performed, and have the expected behaviour. This is the exact u= se case that was described over the years in this mailing list, Now, obviously, this use case is contain within the operator domain. I don'= t expect an operator to have "TI-LFA" on their peering links with other tra= nsit/operator. For people references, page 15 "TI-LFA over SRv6": http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDN= NFV2020-WhitePaper.pdf Thanks, dan From: ipv6 > on behalf = of "Eric Vyncke (evyncke)" > Date: Wednesday, May 6, 2020 at 7:08 AM To: Ron Bonica >, 6man <6man@ietf.org> Subject: [EXT]Re: Routing Header Insertion Ron, All my respect to you for this correction of yours. Regards -=E9ric PS: I was about to reply unicast to Ron but decided that Ron deserves some = public appreciation for his email. From: ipv6 > on behalf = of Ron Bonica > Date: Wednesday, 6 May 2020 at 02:52 To: 6man <6man@ietf.org> Subject: Routing Header Insertion Folks, My apologies to Zafar Ali. Reading through the EANTC report, it appears the= Juniper demonstration SRv6 Routing Header insertion to support TI-LFA. In = that respect, Zafar is correct. However, we should not jump to the conclusion that such behavior is desirab= le. Ron Juniper Business Use Only Juniper Business Use Only Juniper Business Use Only --_000_DM6PR05MB6348B22D75A7015AC966981CAEA50DM6PR05MB6348namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Daniel,

 

TI-LFA with SRH insertion poses problems in the foll= owing cases:

 

  • When the packet already contains an SRH
  • When the= IPv6 Destination Address contains uSIDs

 

In the first case, when the packet already contains = an SRH, TI-LFA with SRH insertion results in a single packet that contains = two SRH’s. No reading of RFC 8200 allows this.

 

The second case is more complex. Assume that in your= uSID strategy:

 

  • The uSID block identifier is 32 bits long
  • Each u= SID is 16 bits long
  • The end-of-carrier marker is also = 16 bits long

 

In this case, you can fit 5 uSIDs in the IPv6 addres= s.

 

On the first segment, when the destination address s= till contains 5 uSIDs, a PLR detects link failure and invokes TI-LFA proced= ures. The repair tunnel contains 3 segments. If the PLR executes TI-LFA wit= h insertion procedures, what does the resulting IPv6 Destination address look like? What does the SRH look l= ike?

 

Yes, the problem can be solved, but not without deep= though and vigorous head scratching. When a solution is that complex, it i= s probably beyond the capability of any operations staff.

 

The above-mentioned problems could have been avoided= if TI-LFA created its repair tunnel by prepending an IPv6 header with its = own SRH.

 

        &nbs= p;             =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            = Ron



 

Juniper Business Use Only

From: Voyer, Daniel <daniel.voyer@bell.ca&= gt;
Sent: Wednesday, May 6, 2020 8:09 AM
To: Eric Vyncke (evyncke) <evyncke@cisco.com>; Ron Bonica <= rbonica@juniper.net>; 6man <6man@ietf.org>
Subject: RE: Routing Header Insertion

 

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

 

Ron, yes – I echo Eric &#= 8211; all my respect.

 

Ron, I for one, would jump to c= onclusion for that specific use case where insertion is performed, and have= the expected behaviour. This is the exact use case that was described over= the years in this mailing list,

 

Now, obviously, this use case i= s contain within the operator domain. I don’t expect an operator to h= ave “TI-LFA” on their peering links with other transit/operator= .

 

For people references, page 15 = “TI-LFA over SRv6”:

http://www.eantc.de/fileadmin/eantc/d= ownloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf=

 

Thanks,

dan

 

From: ipv6= <ipv6-bounces@ietf.org>= on behalf of "Eric Vyncke (evyncke)" <evyncke=3D40cisco.com@dmarc.ietf.org&g= t;
Date: Wednesday, May 6, 2020 at 7:08 AM
To: Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>, 6man <6man@ietf.org>
Subject: [EXT]Re: Routing Header Insertion

 

Ron,

 =

All my respect to you for this correction of yours.<= span lang=3D"EN-CA">

 

Regards

 

-=E9ric

 

PS: I was about to reply unicast to Ron but decided = that Ron deserves some public appreciation for his email.

 

From: ipv6= <ipv6-bounces@ietf.org>= on behalf of Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>
Date: Wednesday, 6 May 2020 at 02:52
To: 6man <6man@ietf.org><= br> Subject: Routing Header Insertion

&nbs= p;

Folk= s,

&nbs= p;

My a= pologies to Zafar Ali. Reading through the EANTC report, it appears the Jun= iper demonstration SRv6 Routing Header insertion to support TI-LFA. In that= respect, Zafar is correct.

&nbs= p;

Howe= ver, we should not jump to the conclusion that such behavior is desirable.<= o:p>

&nbs= p;

&nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       Ron

&nbs= p;

&nbs= p;

Juniper Business= Use Only

&nbs= p;

Juniper Business= Use Only


Juniper Business Use Only

--_000_DM6PR05MB6348B22D75A7015AC966981CAEA50DM6PR05MB6348namp_-- From nobody Thu May 7 10:26:24 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61953A0AA0 for ; Thu, 7 May 2020 10:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=juniper.net header.b=uECL1gw8; dkim=pass (1024-bit key) header.d=juniper.net header.b=Uxc0BeoI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI0UBgSLB534 for ; Thu, 7 May 2020 10:26:21 -0700 (PDT) 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 D9E563A0BFE for <6man@ietf.org>; Thu, 7 May 2020 10:26:20 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 047HLggH028541; Thu, 7 May 2020 10:26:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=n0eidMzzd7znCd2uJFMxgltj9RgMYNRv3WWNQGmx9+4=; b=uECL1gw8dPBoOg5E18w1cPg+MhbjZzfgg5yXGvW15oqRxyZKiT96s7czOCEpShXQe077 0XCKmFpIuliQFhu+bk9Q/4A3w03xTI0of7bk01fIe9lICz4/wDe8gYAqET4NeBBZDHo+ 9del1PjSMasCrmdZ77L+YrXX+Ht8SB6nc89SbfY6AcnSJX4NcY5wAzGDGksXjJ7ZZMt5 /bXtyj37zusQWliKlxKvsE4K5UAx3lFFOlrHus5hqkCUNV2ZuXJrhHZs0Sg0B3iTQHj2 ICY0NndJnbkb50c7BpSAxZWPaqDKEJSfUBIYAgZjCE1pC8aCEI7Sv4jhKu4D6/AfIClt 3w== Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp2053.outbound.protection.outlook.com [104.47.44.53]) by mx0b-00273201.pphosted.com with ESMTP id 30v5u59rgw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 May 2020 10:26:14 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e9B7QzKSu9M4187SO3WmaXnFdIq4fA11fU/lfFSlQO1Ler0PCXvUwBGzgEhJEL1EWgtvcpjmx2FRsF+5EukXno7OpvxeVAZw54JvBPE5q531mKWMTDzc1Yl3VhwGm8l0a23f7etBTIZh67F02os8OdGBg0TZl+5k5PsrevR9aU4e9Eha8dJsNliQKUZ9/E/jUndTHmHU51Oz+g+4/Ey02bhOtkBNgP5/byIhyhbl51sMex0cGwu1ejnmNBRlFa+sRDtYqGFgUyxc0dUpmbrOhNMV55VSvryENBZVXCe0fkFkJ5T48WUHRN5d13SAO0jGHKsIf4aoY0sleyVKA3CfEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n0eidMzzd7znCd2uJFMxgltj9RgMYNRv3WWNQGmx9+4=; b=oIx8AAm1nxMkrJl4r9X7QeJzDhu1nMEJMmrQlsCLYJLfTr0vi5U0uVTDBI9fawyXADOkHzjspb7yJQD5iBW9GNLNuqdUcrYs4B1t78jZ95ERa6jVj9SgMa8kZxl0uLiEjuvUszXZuv3E5YP1IvPurn2Agyizacxi1xxdyeRzmcExy7zd5YBF5gd7Csm+kDVPi0bmpNbollF5ROmTPvcSOikIZkzVhbkunAG7r+sRDR+ZY1YsjCVR7dRgOfgK3Bje111zqhGTTr4j2j1IMdXwMb4udT4xce/jCqFMlZknU2NpMypvuw2sdYblw9z+EFHAyfrvDSjlDbJXfAC+erHdHw== 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=n0eidMzzd7znCd2uJFMxgltj9RgMYNRv3WWNQGmx9+4=; b=Uxc0BeoIZOF/UQn33VQ1JrRLhcT4FzlS5B0gYGmSaqVry6lIcI8pDLNzNx6IcTcv40seT9ueMXOGGizM1Uykfz58XSiaPoFm/OKRxTklaJOGXDHfDwycBSFk0DXqq9Tv+W8pg5yPOSRhZOxfSllyTA+euZkkI4Gc/8Ene30sLRk= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB4201.namprd05.prod.outlook.com (2603:10b6:5:89::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.11; Thu, 7 May 2020 17:26:12 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.2979.028; Thu, 7 May 2020 17:26:12 +0000 From: Ron Bonica To: "Darren Dukes (ddukes)" , Krzysztof Szarkowicz CC: "Voyer, Daniel" , "Eric Vyncke (evyncke)" , 6man <6man@ietf.org> Subject: RE: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AQHWI58t0MrEgFbBRG+Eev5I1WHYlaia/q4AgAHXnICAAAry0A== Date: Thu, 7 May 2020 17:26:12 +0000 Message-ID: References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> In-Reply-To: <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> 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_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-05-07T17:26:09.7979291Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=0dc8cb13-b1cd-4358-b2cf-2c6a0b8836d2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6c3a803e-c8c1-44ea-e76c-08d7f2abbd42 x-ms-traffictypediagnostic: DM6PR05MB4201: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5C2tIfY0qrV8hW0QFJRNxri4Y3IJNS0L4EblWCFTfTFruI8s9OEluMi8zdTmHGOgY+owjARa06KOPrzRMMXw/la7+Jp6CtTpO27Ffr5hFCjTNR9PaBHuIud0LXi6v33R4oduvKzMTALQmQtjPP3mUuHJCVjCgh+gv9WtbZfgL97+c/g6v8bWG4XIYzWNV2QhuXVWP3Oa0T6REirJVi8C/blzh6UNY/FACe1rmHMFaPW0mYzJPJZvUDh4YmDe/XMp3esY5Aa9Pq8EjCNPYve9suKAjrupSZ0/9KkKIy3OUTJBjKz9CCjobi61YgbJjNwTsY/oG/Y7fnv802XsGJ31GWfPG6m6mXP3guBtRBunBzHsNuXdA6FsxV1oN46xkYX2AJbwNaHtZnGeBDR7/cqCEqjt3+gJ8B+DYDymKnqyrh2TsgfZzYtFDnrsEGFEDO909U091e3w6WpJ/sgPUGCL2YuCYkfk5xs371ov57cZ9/kFWVqvPqMHZiqzjVdLNZWxzKq2hzTJJ49t+WhicN+D7C4lIqOSrPcV0C/DKInHxy/3IWx6CySEMJgMtAMga/YTQH/ibNvL2w+tN0EIS31PK91JBejgwdNgKGAB9JacEPs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(366004)(376002)(346002)(396003)(33430700001)(3480700007)(6506007)(86362001)(5660300002)(26005)(53546011)(7696005)(83310400001)(4326008)(2906002)(83300400001)(83290400001)(186003)(52536014)(83320400001)(83280400001)(33656002)(7116003)(76116006)(66556008)(33440700001)(9686003)(66476007)(71200400001)(966005)(478600001)(66446008)(64756008)(110136005)(54906003)(166002)(55016002)(316002)(66946007)(8676002)(83080400001)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: I9KEgdK6Za3NttzuSajA4VqRlnzI1oD8jMWR0Ktr7zDEYeE8adWT8M5TRZKW+lRAACF4AIJ7ew3zjdumu7FLGxi++E1ZKJTwNf6MsqHyq/64NDi9owTrU1VpycMFVQbwuwEg0AK2nqfp0eWnwg6wIkJx6jZcRyXnr1iWiQu5R11YVEJHwIuacH5kMk5Cbu80Gwv5KivKtW0vv+axUYBBBwlcwh/KrZveh6k4dDriupHV5K6pQedVnYOeJjmxQlz2SMLKhMgQtbr3L75bbF5dbFHzG4nOfDaMkr14XVW/dtneEuZARetguwibWOurc/zqtxPjD35l2kpOCWuw9YGz2wFMZSIlLSvtXZJ+s1+fi+imFjwSrNeVm8ipy7+jk+uOwtKvkyPosRo3S4gViRYv2x02almRnpTA6wfNGh0qEZU1YW+arFP70b2iD3EOq4sc8RJQDai1nyNLzrdBU6gqLtusOWQV+JvFcBkALfjm2fdDq6Wd+OYr6fuTxETnffEnJpVPj+mAxvl1XU0rYqC4qR8vl5lqpdAM0UISdzIhnR5viIj+veGemrY69JPscaX1h2fVXAxDavf+711lG971tzf9jKbtUIeNZR4pMMdZkgo9kaBz8J5mQ0OyRYeNiWWQ9DUx4blubNXqRgEXREGApshtFHqVZMl7U2rkh2UK1eXJq3XmEiUTXwzaA3RWVd4ezO4mpq3ytG9TEZdx6rT+1cSL3sO7oqXRENO+G0Ze9J9hzGonokXjbN8IY+NuzStrBryf4MXQOq+6oCJTcEoVS+AV2U8ZoZwiQVhkOIsNSYM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB6348DAF3CA331E3F7318A66CAEA50DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 6c3a803e-c8c1-44ea-e76c-08d7f2abbd42 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 17:26:12.3992 (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: Pzz/f05JtNQvN3YRiIHsHAWkJBAm0P/hB2BIjrh7ZEX0pTHoJWhh+YFqtb6ctpEweubZ78bv+sUIQ4zD73yspg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4201 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-07_10:2020-05-07, 2020-05-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 impostorscore=0 priorityscore=1501 clxscore=1031 lowpriorityscore=0 phishscore=0 suspectscore=0 mlxscore=0 malwarescore=0 adultscore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005070141 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 17:26:23 -0000 --_000_DM6PR05MB6348DAF3CA331E3F7318A66CAEA50DM6PR05MB6348namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Darren, I would not infer that Juniper sees SRH insertion as desirable. Ron Juniper Business Use Only From: Darren Dukes (ddukes) Sent: Thursday, May 7, 2020 12:44 PM To: Krzysztof Szarkowicz Cc: Voyer, Daniel ; Ron Bonica ;= Eric Vyncke (evyncke) ; 6man <6man@ietf.org> Subject: Re: Routing Header Insertion [External Email. Be cautious of content] Krzysztof thanks for the link, to me it does seem that Juniper sees SRH ins= ertion for TILFA as desirable, as documented in draft-voyer-6man-extension-= header-insertion. So Dan, I think we can jump to that conclusion supported by 19 implementati= ons and 5 deployments as captured in draft-matsushima-spring-srv6-deploymen= t-status, including Juniper's. Darren On May 6, 2020, at 8:36 AM, Krzysztof Szarkowicz > wrote: Also, There is short video discussing SRv6 TI-LFA EANTC test: https://youtu.be/v9woK-7AiyA Thanks, Krzysztof On 2020 -May-06, at 14:09, Voyer, Daniel > wrote: Ron, yes - I echo Eric - all my respect. Ron, I for one, would jump to conclusion for that specific use case where i= nsertion is performed, and have the expected behaviour. This is the exact u= se case that was described over the years in this mailing list, Now, obviously, this use case is contain within the operator domain. I don'= t expect an operator to have "TI-LFA" on their peering links with other tra= nsit/operator. For people references, page 15 "TI-LFA over SRv6": http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDN= NFV2020-WhitePaper.pdf Thanks, dan From: ipv6 > on behalf = of "Eric Vyncke (evyncke)" > Date: Wednesday, May 6, 2020 at 7:08 AM To: Ron Bonica >, 6man <6man@ietf.org> Subject: [EXT]Re: Routing Header Insertion Ron, All my respect to you for this correction of yours. Regards -=E9ric PS: I was about to reply unicast to Ron but decided that Ron deserves some = public appreciation for his email. From: ipv6 > on behalf = of Ron Bonica > Date: Wednesday, 6 May 2020 at 02:52 To: 6man <6man@ietf.org> Subject: Routing Header Insertion Folks, My apologies to Zafar Ali. Reading through the EANTC report, it appears the= Juniper demonstration SRv6 Routing Header insertion to support TI-LFA. In = that respect, Zafar is correct. However, we should not jump to the conclusion that such behavior is desirab= le. Ron Juniper Business Use Only Juniper Business Use Only -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- Juniper Business Use Only --_000_DM6PR05MB6348DAF3CA331E3F7318A66CAEA50DM6PR05MB6348namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Darren,

 

I would not infer that Juniper sees SRH insertion as= desirable.

 

        &nbs= p;            &= nbsp;           &nbs= p;             =             &nb= sp;        Ron

 

 

 

Juniper Business Use Only

From: Darren Dukes (ddukes) <ddukes=3D40ci= sco.com@dmarc.ietf.org>
Sent: Thursday, May 7, 2020 12:44 PM
To: Krzysztof Szarkowicz <kszarkowicz@gmail.com>
Cc: Voyer, Daniel <daniel.voyer@bell.ca>; Ron Bonica <rboni= ca@juniper.net>; Eric Vyncke (evyncke) <evyncke@cisco.com>; 6man &= lt;6man@ietf.org>
Subject: Re: Routing Header Insertion

 

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

 

Krzysztof thanks for = the link, to me it does seem that Juniper sees SRH insertion for TILFA as d= esirable, as documented in draft-voyer-6man-extension-header-insertion.

So Dan, I think we can jump to that conclusion supported by 19 impleme= ntations and 5 deployments as captured in draft-matsushima-spring-srv6= -deployment-status, including Juniper's.

Darren

 

On May 6, 2020, at 8:36 AM, Krzysztof Szarkowicz <= ;kszarkowicz@gmail.com> wro= te:

 

Also,

 

There is short video discussing SRv6 TI-LFA EANTC te= st:

 

 

Thanks,

Krzysztof

 

On 2020 -May-06, at 14:09, Voyer, Daniel <daniel.voyer@bell.ca> wrote:

 

Ron, yes – I echo Eric – all my respect.=

 

Ron, I for one, would jump to conclusion for that sp= ecific use case where insertion is performed, and have the expected behavio= ur. This is the exact use case that was described over the years in this ma= iling list,

 

Now, obviously, this use case is contain within the = operator domain. I don’t expect an operator to have “TI-LFAR= 21; on their peering links with other transit/operator.

 

For people references, page 15 “TI-LFA over SR= v6”:

 

Thanks,

dan

 

From: ipv6 <ipv6-bounces@ietf.org> on behalf of "Eric Vyncke (evyncke)" <evyncke=3D40cisco.com@= dmarc.ietf.org>
Date: Wednesday, M= ay 6, 2020 at 7:08 AM
To: Ron Bonica <= ;rbonica=3D40juniper.net@dmarc.ietf.org>, 6man &= lt;6man@ietf= .org>
Subject: [EXT]Re: = Routing Header Insertion

 

Ron,

 

All my respect to you for this correction of yours.<= o:p>

 

Regards

 

-=E9ric

 

PS: I was about to reply unicast to Ron but decided = that Ron deserves some public appreciation for his email.

 

From: ipv6 <ipv6-bounces@ietf.org> on behalf of Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>
Date: Wednesday, 6= May 2020 at 02:52
To: 6man <6man@ietf.org>
Subject: Routing H= eader Insertion

 

Folks,

 

My apologies to Zafar Ali. Reading through the EANTC= report, it appears the Juniper demonstration SRv6 Routing Header insertion= to support TI-LFA. In that respect, Zafar is correct.

 

However, we should not jump to the conclusion that s= uch behavior is desirable.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            Ron

 

 

Juniper Business Use Only=

 

Juniper Business Use Only

--------------------------------------------------= ------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: =
https://www.ietf.org/mailman/listinfo/= ipv6
--------------------------------------------------------------------
=

 

----------------------------------------------------= ----------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

 


Juniper Business Use Only

--_000_DM6PR05MB6348DAF3CA331E3F7318A66CAEA50DM6PR05MB6348namp_-- From nobody Thu May 7 10:27:57 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67B23A0C08 for ; Thu, 7 May 2020 10:27:52 -0700 (PDT) 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, 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=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spvkJqpd8bAc for ; Thu, 7 May 2020 10:27:50 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 104EF3A0AA0 for <6man@ietf.org>; Thu, 7 May 2020 10:27:49 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id p16so6086558edm.10 for <6man@ietf.org>; Thu, 07 May 2020 10:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lDGDmxPkvgT/Lyb7u0tooSEBcv1a/aWu0QOxLY8/ATI=; b=L9zkp85Z2zdRhhQ+oxIdPYF4JiB6G66owXhf42QdJSQFZY+8SX26OtfC/heP1Y2Gmp 2KmjNKkZ5zwUpxyQ0bg3EsB/kxl6lPDKCJDjKuxUqVC+MIRYKv/hTzvRcFkVAojuLziK vBqAcKeWKda6vQ8GKLIUg2UYFYTP6GLCoXwjWcTJn3br6Km6FkBrIzfMCmhrCD2YNkpu 3/VC41PbGON8cG5CqTk+Pm3AmkGoNjuNFfl5MeK1duMcMGA3JLos2sFgK+8IKRt69bWL 0HDCZey2HowhYTTr1OVxix43Z31ZrlMfanDmaVrJxzCO7sr11I5N62REoxuZ14Ye5gWJ solA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lDGDmxPkvgT/Lyb7u0tooSEBcv1a/aWu0QOxLY8/ATI=; b=R1a7FqjguUuecbqz7oGfUhlTl2Xgz/+WF/OlPaXOvGd1QV7OTenOqmIGYJZat8JvuJ acb6QF6OuVxh4gurCa6FJYhiyrhuRtiQvMV/cOKkGhPosXnaQguieMKqrSzIzbcMpKfu fQEAC4N8uowoeq1hjpbkr0jSm2ig2RuBduHk3GqD9HoYHMWI4KSPeiz6ixWcIH4sPb0g TvjoFwM4gD06Vo84kS4Lg8EQKGNDrRQynKXEBwF3DWeVQLGBGLB6wKovrxk5lJUBqffz RAs8Z7eawdpNsohuxcnccsOzPzkAtY01B+/WGJ3ctgSEvJXLym7rPoP/A3WgfwZ5mHRu stzQ== X-Gm-Message-State: AGi0PuZv5lvKBvsh/p+hKVkPkKKwn9UROX6Z65xHOC6bUDYtaMKWNqFX qFVvJHTHQRdrT1VKAbyWiUS61bcCBuXg1wTSnn6dAw== X-Google-Smtp-Source: APiQypJ1PHYRuJE/8X5a529XHjR+yx48iS59/USCYd2bLF+CB1qzrazk2XdPE2SceiNk6z6NGHPa64hFPJlFe72INNc= X-Received: by 2002:aa7:d4cd:: with SMTP id t13mr12921739edr.30.1588872468407; Thu, 07 May 2020 10:27:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Thu, 7 May 2020 19:27:39 +0200 Message-ID: Subject: Re: Routing Header Insertion To: Ron Bonica Cc: "Voyer, Daniel" , "Eric Vyncke (evyncke)" , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000012b5dc05a5123396" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 17:27:53 -0000 --00000000000012b5dc05a5123396 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ron, > Yes, the problem can be solved, but not without deep though and vigorous head scratching. Well don't we still have the indicators of Active, Next and Last uSIDs in SRH ? If so what is so difficult if you keep your original SRH as is and provide FRR using new SRH ? Moreover if you POP the additional SRH @ ptotectied path PHP FRR endpoint may not even noticed he is acting as such endpoint and that is very cool thing. The problem perhaps becomes a nice exercise to solve how to handle TI-LFA when you have uSID list in DA address of the packets and where there is no SRH at all :) Clearly a valid deployment scenario. But since you are already deep into it I will let you figure it out :) > When a solution is that complex, it is probably beyond the capability of any operations staff. Well it would be a mistake to count on all operators doing this handling in P4 code on their own custom platforms. For rest of them a simple knob would be sufficient to enable it and enjoy. Thx, R. On Thu, May 7, 2020 at 7:03 PM Ron Bonica wrote: > Hi Daniel, > > > > TI-LFA with SRH insertion poses problems in the following cases: > > > > - When the packet already contains an SRH > - When the IPv6 Destination Address contains uSIDs > > > > In the first case, when the packet already contains an SRH, TI-LFA with > SRH insertion results in a single packet that contains two SRH=E2=80=99s.= No > reading of RFC 8200 allows this. > > > > The second case is more complex. Assume that in your uSID strategy: > > > > - The uSID block identifier is 32 bits long > - Each uSID is 16 bits long > - The end-of-carrier marker is also 16 bits long > > > > In this case, you can fit 5 uSIDs in the IPv6 address. > > > > On the first segment, when the destination address still contains 5 uSIDs= , > a PLR detects link failure and invokes TI-LFA procedures. The repair tunn= el > contains 3 segments. If the PLR executes TI-LFA with insertion procedures= , > what does the resulting IPv6 Destination address look like? What does the > SRH look like? > > > > Yes, the problem can be solved, but not without deep though and vigorous > head scratching. When a solution is that complex, it is probably beyond t= he > capability of any operations staff. > > > > The above-mentioned problems could have been avoided if TI-LFA created it= s > repair tunnel by prepending an IPv6 header with its own SRH. > > > > > = Ron > --00000000000012b5dc05a5123396 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ron,

>=C2=A0 Yes, the = problem can be solved, but not without deep though and vigorous head scratc= hing.=C2=A0

Well don't we still have the indic= ators of Active, Next and Last uSIDs in SRH ? If so what is so difficult if= you keep your original SRH as is and provide FRR using new SRH ? Moreover = if you POP the additional SRH @ ptotectied path PHP FRR endpoint may not ev= en noticed he is acting as such endpoint and that is very cool thing.=C2=A0=

The problem perhaps becomes a nice exercise=C2=A0= to solve how to handle TI-LFA when you have uSID list in DA address of the = packets and where there is no SRH at all :) Clearly a valid=C2=A0deployment= scenario. But since you are already deep into it I will let you figure it = out :)=C2=A0

> When a solution is that complex,= it is probably beyond the capability of any operations staff.=C2=A0=C2=A0<= br>

Well it would be a mistake to count on all ope= rators doing this handling in P4 code on their own custom platforms. For re= st of them a simple knob would be sufficient=C2=A0to enable it and enjoy.= =C2=A0

Thx,
R.


<= div class=3D"gmail_quote">
On Thu, May= 7, 2020 at 7:03 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:

Hi Daniel,

=C2=A0

TI-LFA with SRH insertion poses problems in the foll= owing cases:

=C2=A0

  • When the packet already contains an SRH
  • When the IPv6 Destination Addres= s contains uSIDs

=C2=A0

In the first case, when the packet already contains = an SRH, TI-LFA with SRH insertion results in a single packet that contains = two SRH=E2=80=99s. No reading of RFC 8200 allows this.

=C2=A0

The second case is more complex. Assume that in your= uSID strategy:

=C2=A0

  • The uSID block identifier is 32 bits long<= /u>
  • Each uSID is 16 bits long
  • The end-of-carrier marker is al= so 16 bits long

=C2=A0

In this case, you can fit 5 uSIDs in the IPv6 addres= s.

=C2=A0

On the first segment, when the destination address s= till contains 5 uSIDs, a PLR detects link failure and invokes TI-LFA proced= ures. The repair tunnel contains 3 segments. If the PLR executes TI-LFA wit= h insertion procedures, what does the resulting IPv6 Destination address look like? What does the SRH look l= ike?

=C2=A0

Yes, the problem can be solved, but not without deep= though and vigorous head scratching. When a solution is that complex, it i= s probably beyond the capability of any operations staff.

=C2=A0

The above-mentioned problems could have been avoided= if TI-LFA created its repair tunnel by prepending an IPv6 header with its = own SRH.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Ron

--00000000000012b5dc05a5123396-- From nobody Thu May 7 10:46:49 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3C43A0CD2 for ; Thu, 7 May 2020 10:46:46 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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_H2=-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=mkvPNJNs; dkim=pass (1024-bit key) header.d=juniper.net header.b=XbUdAmXO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lblUCqNk9FKf for ; Thu, 7 May 2020 10:46:44 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DD23A0CAA for <6man@ietf.org>; Thu, 7 May 2020 10:46:42 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 047HhIq9032436; Thu, 7 May 2020 10:46:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=xxivCP2Aq4GTJr3DLFgv9d4ZOveJe3fCQVMQif2q3tA=; b=mkvPNJNsHlZMEa3ud0Vf6LMoye+ApffvYI1rZVRzpidkIy8JkGlj+28WV0yMdizJM4h3 q1raIgyEcJabLzp/NZ4n4KS3+bPL45PxWmJMv+/Wq8HHD8A4C0r62h2jZwEjsWo+WxBl gofhFreC6krXzCzuz41QAeg9q4L9JCyyIANHC72xHY2K+aUx1sOoteY/iPv1N8Tnye9Z gEL7tRcuHor+9YTkcJFazedJ7oVXZTYl6opJoBydJElPWDGcDC0aO5Z/i0yhzGUL4B4P 9uuuNdlGjxQr9p9wfa+c/VkYXAaTx8TMBMT06wD1FcbyuJts75M+sBatg8vBE0ZnBeWr Jg== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2053.outbound.protection.outlook.com [104.47.45.53]) by mx0a-00273201.pphosted.com with ESMTP id 30vbfgs9n1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 May 2020 10:46:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ch7ifI86x0FBoGdMkZFOAFyHti1zReN6OJ7T19ZwJRg92IK20eg5XiegKcUxYIufjp++QqGu8KCqAgqh3VXxTnmleq9bJnvILcP2PW8d1oKlC1BkCmoytLUdunrhpUHAFtfAyMBX/GsO9OUmlN12a8MPsTU0kRvYbS1/K9ZyszlJMPXRpgI4rcRhBq2Rujbb5g3zTxh0BuX/AMGY7hRVmuZHO1wNKeI6m3zbNckD7ETKwMIzSAyCHvjMHQT8uxHI3BmoPWcxKxt+pKbNpBuFm1LuijTvnCkiNKZ1i3+WvdoFSYlUE1IRNRSnPlZUwvP7jA6pxAftgcHc9T1o3+VHVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xxivCP2Aq4GTJr3DLFgv9d4ZOveJe3fCQVMQif2q3tA=; b=XCOr0CUvJDPikeMTusIqaouNCiwr8e3UkG5+jqy7+tjyfXaxB8JuOC4x3oBqFBPWAa2EGV1AENhCHautGyZL28e2JZz+gomdADEt4tiDy1WdETYklHQ9FHIDwVWH4IuXEb7NO7YeMch3ViAcKlozdOGwxD9bxLJ7zkzXMsmonEc8GzghC+pDckL6VjpWvAumcMPTYsgdvhZszE+5lyq0qWbEF9ZmoJSMcLa1X6IvibsNVLRs3t/uhQZddUptKy1aHkZafxKg4utBfjuueWBfVghlCQXnrwoz2uFICX78IppIWf8u7dtOlZFCoT8HHlBKYhBEmiZL6V8NVyeFHgEOow== 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=xxivCP2Aq4GTJr3DLFgv9d4ZOveJe3fCQVMQif2q3tA=; b=XbUdAmXOYNnyEZ4i/kKuMqJnD/R/pwx51gbJei34Uxr5acKHtOiSPX5g4+5GpJjXyhEOdBfj7IUmUDSCJRA6v9UUlKOWEIFZran9PbLW4cqVsSsAj0ZHzyLWToJfzXzqAc27rhnkL2H6Dw3r1kWB1191A9y7pEs5ptVDy/dCyP8= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB5433.namprd05.prod.outlook.com (2603:10b6:5:56::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.11; Thu, 7 May 2020 17:46:31 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.2979.028; Thu, 7 May 2020 17:46:31 +0000 From: Ron Bonica To: Robert Raszuk CC: "Voyer, Daniel" , "Eric Vyncke (evyncke)" , 6man <6man@ietf.org> Subject: RE: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AQHWI58t0MrEgFbBRG+Eev5I1WHYlaic0H/ggAAR34CAAAMfkA== Date: Thu, 7 May 2020 17:46:30 +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_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-05-07T17:46:28.3014948Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=8caa9d78-5236-4615-9fa1-de62be9b9211; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d6df08d5-e9e2-4692-99fe-08d7f2ae9390 x-ms-traffictypediagnostic: DM6PR05MB5433: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xTcuKIty3t4BTclKJRuKs03usjGnCl14UgWgt/ldgfXNbrRLK5BmYraX5QKKd+8vZlSG8gLSf968s3BRuDsBkI7l/n5YACE9w97x/mbp8iD7J8KMHXdxBGAVh8RnXJ41NVKWRsYR1OCAskCWj3ZHd1fB/iIxfZlpKpQO7DlMoIUFN/eTsCoZlfRsob+YlY1GuWuUUaBwyIsEmqhI/CjhtxTcFbqtzgufzG7dKh/lP7kYjQl3eK1zNJ+F/bD3vF1VwkQzRGfk7N8aKcBhOOPC3qlfxzz9IK63biDeQGs4k9RCT/cRMvGmfgaJZDqpAwP40oejmhv80JEOYXguVlQtzdJfBVVmYkexSFL3ZseUU04rIbvuzOzrL8rZmhenrhVlFzTFqsUCzLGZsob7N3Onb3Td5crzK76Z6e3/xN9KUUlhZzBXn4jPw1jCRkqQBtwaloXx0XgxTmbzHpIEQeqxecfGcS4nDM+9j46g8T0Y9XXsDVpLY8nlvm7jkjl9XjL7mY7t8EiXbYHvdkW2Pkox7w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(366004)(346002)(396003)(39860400002)(33430700001)(8936002)(55016002)(316002)(4326008)(3480700007)(9686003)(54906003)(6916009)(7696005)(7116003)(71200400001)(33656002)(478600001)(2906002)(64756008)(5660300002)(6506007)(186003)(53546011)(83310400001)(26005)(83290400001)(52536014)(66446008)(66476007)(66556008)(83320400001)(83280400001)(86362001)(76116006)(66946007)(83300400001)(33440700001)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: XwC0uD3vF/CUYTonpYBePwmCP+ti9RleCAvj2J7X4rloaI/Vr9DlC4wQcD4liA2T8FCuvQfArsX/MmttlM866j2qegMbEarHenDac9AoVyhVxWB3B6ooVVX0AePXIRcGJ++JAobIQ7AS5nl5L4KkotDz4AUu+RZZijT7syUZWyrcFpzEfNZ1zNz7TUvMju5hkD+U9A1SJU23jK5GSFEBBFVBZlI/NEQzZPM9fn2t6tutZxXuHsybuTQV0um7cdMIIE+DhF5Ka5FLiDR+hr1KEqf/yYqkpOpRjweUz+Pa/Tn+mZKejRGkRQ+rcKoAJifFIxsM1o6EBt1l65RvKXuoWcNJTGiePnpNJvCN0yStN199HUF31O+EkrCzEyG1bkkI2Gh1JKxoWTs+NiCND4fntT/ai37OHwNdXqfwSqVt6klo80LYaBOGz+Sb5mtExIdWn03xYcfsGQCSuR4OI3ijCfa3Cdzuo9ptRfTgRP8Ykh3B+/WHJ7kWerH3XCF8/Z8zyvAieYV/24y7vXUJQ8kn/JUUL6oeWJivPgNnAllYp3ontVzFp56gFBfd45xlaAnGIWI17FiIwp9ETYM+lGhm2d4Y8PmFtTBxMiz7UXLbeYpREarr00GorcilHqMKAjXeZ2tiB/RuwJOxXDm8PcpL28y1CuuXdhAURxuABahEC4mttQ0rc+Xssqw40lUq87DBNEcpBTqLfOBlE96Dll0Q9/ruo0ezHIhf4jiUxAo5DuOvq8h/1Q8ThO/RbQxXcIHvnNQ4MkjzWlgR/gByaxqJrzvHYvyKcTUQ06DLtrMunoU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB6348870F8D1934BC136F1089AEA50DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: d6df08d5-e9e2-4692-99fe-08d7f2ae9390 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 17:46:30.9513 (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: DinWXPbu/LmhpeVWFteLjW+EzVhfhAWf/t0prSTdU0RMZG+g1oyybhXRA9XOaT472NGrRPXwzryd6delfpLEyA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5433 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-07_10:2020-05-07, 2020-05-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 phishscore=0 clxscore=1031 mlxscore=0 bulkscore=0 suspectscore=0 malwarescore=0 spamscore=0 adultscore=0 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005070144 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 17:46:47 -0000 --_000_DM6PR05MB6348870F8D1934BC136F1089AEA50DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, The problem is that the IPv6 destination address contains 5 uSID that repre= sent 5 nodes yet to be visited. Those need to be put at the end of the line= , so that they are visited *after* the nodes in the repair path. Yes, there are some very clever solutions that you and I understand. But wi= ll the guy in the NOC who doesn't live and breath SR be able to figure it o= ut the first time he sees it. = Ron Juniper Business Use Only From: Robert Raszuk Sent: Thursday, May 7, 2020 1:28 PM To: Ron Bonica Cc: Voyer, Daniel ; Eric Vyncke (evyncke) ; 6man <6man@ietf.org> Subject: Re: Routing Header Insertion [External Email. Be cautious of content] Hi Ron, > Yes, the problem can be solved, but not without deep though and vigorous= head scratching. Well don't we still have the indicators of Active, Next and Last uSIDs in S= RH ? If so what is so difficult if you keep your original SRH as is and pro= vide FRR using new SRH ? Moreover if you POP the additional SRH @ ptotectie= d path PHP FRR endpoint may not even noticed he is acting as such endpoint = and that is very cool thing. The problem perhaps becomes a nice exercise to solve how to handle TI-LFA w= hen you have uSID list in DA address of the packets and where there is no S= RH at all :) Clearly a valid deployment scenario. But since you are already= deep into it I will let you figure it out :) > When a solution is that complex, it is probably beyond the capability of = any operations staff. Well it would be a mistake to count on all operators doing this handling in= P4 code on their own custom platforms. For rest of them a simple knob woul= d be sufficient to enable it and enjoy. Thx, R. On Thu, May 7, 2020 at 7:03 PM Ron Bonica > wrote: Hi Daniel, TI-LFA with SRH insertion poses problems in the following cases: * When the packet already contains an SRH * When the IPv6 Destination Address contains uSIDs In the first case, when the packet already contains an SRH, TI-LFA with SRH= insertion results in a single packet that contains two SRH's. No reading o= f RFC 8200 allows this. The second case is more complex. Assume that in your uSID strategy: * The uSID block identifier is 32 bits long * Each uSID is 16 bits long * The end-of-carrier marker is also 16 bits long In this case, you can fit 5 uSIDs in the IPv6 address. On the first segment, when the destination address still contains 5 uSIDs, = a PLR detects link failure and invokes TI-LFA procedures. The repair tunnel= contains 3 segments. If the PLR executes TI-LFA with insertion procedures,= what does the resulting IPv6 Destination address look like? What does the = SRH look like? Yes, the problem can be solved, but not without deep though and vigorous he= ad scratching. When a solution is that complex, it is probably beyond the c= apability of any operations staff. The above-mentioned problems could have been avoided if TI-LFA created its = repair tunnel by prepending an IPv6 header with its own SRH. = Ron Juniper Business Use Only --_000_DM6PR05MB6348870F8D1934BC136F1089AEA50DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Robert,

 

The problem is that the IPv6 destination address con= tains 5 uSID that represent 5 nodes yet to be visited. Those need to be put= at the end of the line, so that they are visited *after* the nodes = in the repair path.

 

Yes, there are some very clever solutions that you a= nd I understand. But will the guy in the NOC who doesn’t live and bre= ath SR be able to figure it out the first time he sees it.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Ron

 

 

 

Juniper Business Use Only

From: Robert Raszuk <robert@raszuk.net>=
Sent: Thursday, May 7, 2020 1:28 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Voyer, Daniel <daniel.voyer@bell.ca>; Eric Vyncke (evyncke= ) <evyncke@cisco.com>; 6man <6man@ietf.org>
Subject: Re: Routing Header Insertion

 

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

 

Hi Ron,

 

>  Yes, the problem can be solved, but not w= ithout deep though and vigorous head scratching. 

 

Well don't we still have the indicators of Active, N= ext and Last uSIDs in SRH ? If so what is so difficult if you keep your ori= ginal SRH as is and provide FRR using new SRH ? Moreover if you POP the add= itional SRH @ ptotectied path PHP FRR endpoint may not even noticed he is acting as such endpoint and that i= s very cool thing. 

 

The problem perhaps becomes a nice exercise to = solve how to handle TI-LFA when you have uSID list in DA address of the pac= kets and where there is no SRH at all :) Clearly a valid deployment sc= enario. But since you are already deep into it I will let you figure it out :) 

 

> When a solution is that complex, it is probably= beyond the capability of any operations staff.  

 

Well it would be a mistake to count on all operators= doing this handling in P4 code on their own custom platforms. For rest of = them a simple knob would be sufficient to enable it and enjoy. 

 

Thx,

R.

 

 

On Thu, May 7, 2020 at 7:03 PM Ron Bonica <rbonic= a=3D40juniper.net@dmarc.iet= f.org> wrote:

Hi Daniel,

 

TI-LFA with SRH insertion poses problems in the following cases:

 

  • When the packet already contains an SRH
  • When the IPv6 Destination Address contains uSIDs

 

In the first case, when the packet already contains an SRH, TI-LFA= with SRH insertion results in a single packet that contains two SRH’= s. No reading of RFC 8200 allows this.

 

The second case is more complex. Assume that in your uSID strategy= :

 

  • The uSID block identifier is 32 bits long
  • Each uSID is 16 bits long
  • The end-of-carrier marker is also 16 bits long

 

In this case, you can fit 5 uSIDs in the IPv6 address.

 

On the first segment, when the destination address still contains = 5 uSIDs, a PLR detects link failure and invokes TI-LFA procedures. The repa= ir tunnel contains 3 segments. If the PLR executes TI-LFA with insertion procedures, what does the resulting IPv= 6 Destination address look like? What does the SRH look like?

 

Yes, the problem can be solved, but not without deep though and vi= gorous head scratching. When a solution is that complex, it is probably bey= ond the capability of any operations staff.

 

The above-mentioned problems could have been avoided if TI-LFA cre= ated its repair tunnel by prepending an IPv6 header with its own SRH.<= /o:p>

 

            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;          Ron=


Juniper Business Use Only

--_000_DM6PR05MB6348870F8D1934BC136F1089AEA50DM6PR05MB6348namp_-- From nobody Thu May 7 15:57:31 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9EB3A0E2A for ; Thu, 7 May 2020 15:57:27 -0700 (PDT) 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, 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 (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxRHcob9nixP for ; Thu, 7 May 2020 15:57:24 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 CD4EA3A0C61 for <6man@ietf.org>; Thu, 7 May 2020 15:57:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A962F49; Fri, 8 May 2020 00:57:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1588892238; bh=BLH7nJELZMbULfC+sgp EDFfv9aG1qAlaSAdV7THYXmM=; b=bDs3vh1jqQQITL24u0hsepIOzFOFJUOYdLM NHErJ9ldEzdpKlBLUyOreKyCz75vdwTuJMCl/Na4zgEeWBPI7AvhkZjT8r95kVUU zNFWxF/oVn+ozbjLhmFTjQarythQM/msWSXD+IZxhYgG9CVrrr8GDfh6gzPYxI4j SkS39dfY= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NjGy2BYhKcQ0; Fri, 8 May 2020 00:57:18 +0200 (CEST) Received: from [IPv6:2a02:a213:a300:ce80:74d9:69fc:8dc5:b19a] (unknown [IPv6:2a02:a213:a300:ce80:74d9:69fc:8dc5:b19a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 5B94A3C; Fri, 8 May 2020 00:57:18 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <34540284-7163-4176-8DBC-0A186A9A535A@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_01B15BFA-A718-4AE1-8FA6-E0BDDB5E1E5F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Routing Header Insertion Date: Fri, 8 May 2020 00:57:16 +0200 In-Reply-To: Cc: Robert Raszuk , 6man <6man@ietf.org> To: Ron Bonica References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 22:57:29 -0000 --Apple-Mail=_01B15BFA-A718-4AE1-8FA6-E0BDDB5E1E5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > Yes, there are some very clever solutions that you and I understand. = But will the guy in the NOC who doesn=E2=80=99t live and breath SR be = able to figure it out the first time he sees it. We are not the only audience of our drafts. We design protocols to be = used on networks run by operators. Operators who will encounter bugs, = misconfigurations and unexpected behaviour. Yes, there is a level of = abstraction beyond which the operator shouldn't need to understand the = exact implementation. But IPv6 addresses and extension headers are = absolutely within the domain that the operator does need to = understand... If the people in this group (who are far above the expertise level of = the average NOC) sometimes have difficulty understanding the dynamics, = we are writing documents which are of very bad quality because they are = unreadable to most of our target audience... Cheers, Sander --Apple-Mail=_01B15BFA-A718-4AE1-8FA6-E0BDDB5E1E5F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEl13OIanoifT0p8LWWPjdc9pon8sFAl60kkwACgkQWPjdc9po n8uufRAAvBplpO3WMbNuRmHUa9epc5DWmBwxUgNlMDr49MsCg3DHIFPGavb0i7oU 7yi+bR7vfXq8cJbutMlWO3sjCtb4OzrCi3kPrBRirykrj+97dvt+dw7feifdSKaN GHIAxfNiI9U2jKmb2IIuAAXFOXz3q/tzd5TvSszErQ6Qlb9ESb8GixCG9yQwnlJg xNxpOVYDN8bxctuDs1pZ+0Abbso9iKA3XsN/XEsGJR+Rt/SmU8j7+edDMo9xeNGw ulLX9prdL6RRXEKCVph0jvqOUNwK+IlXFVnuZtAtp21FUYBBW4am1w+ZFYFjEKvG H3d+jgLgfc0p7IOtVTh8t2MuA1A2d/aiq7I0tvjKHaw+6ruEImldDOptPnvcTI1b Y+l0dvuMg48dtO1scBqhd2bzYMOd3a6kZgJ0L6Fsphd6UKE8TXgYcJAn/C6rsbQz lkx3VQNe4P/G5NIpu4mJcCWX+f2gc/PMU6yLFkFll1xQbbEDAmUIAdvIqkJdW7u0 6TWhRdM6IdJ+yRE3pHw7hdYVx4fRu7jVw1WgC3ms7cCd0A4C/5Op/TW6cuHLd+9J ZqQkdk/a/SQDoJ1mjVb68ubJ+g14m05J9erhmbkW/+dELDbxw1smsd2CcAflEVa/ kjW9CR3IOgZWpOdr/cbkujRiTcR5X4MRqRrwe73+U+sn5OcJpSk= =qMfS -----END PGP SIGNATURE----- --Apple-Mail=_01B15BFA-A718-4AE1-8FA6-E0BDDB5E1E5F-- From nobody Fri May 8 00:45:47 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2593A3A0872 for ; Fri, 8 May 2020 00:45:44 -0700 (PDT) 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 cVzA3mo1xPRe for ; Fri, 8 May 2020 00:45:41 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 91FC63A0870 for ; Fri, 8 May 2020 00:45:41 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id d16so524130edv.8 for ; Fri, 08 May 2020 00:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dJ8nUvN0TGeUtx72iTOqJTdbpo2SosTXUH1qO7x0tyI=; b=BNwrAp6Cx4nDav+SijyhlHUO5a+vRTlwLugOjSI9u9ikcwSnB/DcuMwYB7jOVjQ6KF /JpE4zZqe45z5vDLJHsTTsm5/E2npBRVsCkC4l+Vcz27My+1rUXmhVw/2rwi91ZuRSF3 y9z3UVfiduEP62eBVmwiGCbuCGCi8fr1DQ6u+q+f4J0emWLnMVSSUN9UNl0bTp8nu/dV CIslgXZs28wW1mjvfcViT0atAVkVjX1N+evvjxsTHHGOil8EJ+MBicyVdb9je7/Ib9Fw Umnkei+N9UOHwDA8YPdvVSSN61ZOrWbwyuK5RIvbWyFYD6YevRfUlaKqkAV3bLm02jil w3Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dJ8nUvN0TGeUtx72iTOqJTdbpo2SosTXUH1qO7x0tyI=; b=tMc1MLDSoz+KZ+oQzsiiKZuLD3LxJFkPuGeNqEk7x1QOmda+i+Yjp98EqkI6xxjIZj bJiG0HWd0tEt4Hq6j5EzOXgcqpoMYlSiDad6Rgr7hzDCY4R/TKJuSB+uE5ZTPCkbTWey kvHm3wJCoByh7R0u69/je+HIQWa7D4GzWa37NuomSoBL8FWQdTELXeA4JKz1qoCUGw/s fwx8IJmCWnTDrcqiis5dNQ+dFucuvTWG07cfQ20ZbuZsOsom0VW6Zh4Bzmqk74D2vMsM fD+8BKGWh6DgTnsTf4MlE2fh+nwWYT1q0TiiQg1uJpRDVO1kkKjsYLzHKEhCdwR1DT0X tTCg== X-Gm-Message-State: AGi0PuZvAEpR2/wH9/v5NNUJwc5/2bsWcSCqQqd1TnhgynvS6t+9bVu6 ycBx3suhY7RqddogaPUF2ywjE/iECxjEK2D+JvWn1IKY X-Google-Smtp-Source: APiQypJPByyvYV5+gjq6ujXL6MAZ+I37X/vew703BvhniBkmMs++enSaZVaT37JjpFAZ1U9+2qWgSoK4oWtt/B+Iyso= X-Received: by 2002:a50:c016:: with SMTP id r22mr1002995edb.388.1588923939637; Fri, 08 May 2020 00:45:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: prabhakar lakhera Date: Fri, 8 May 2020 00:45:27 -0700 Message-ID: Subject: Re: RFC 7527 Optimistic Duplicate Address Detection (DAD) for IPv6 and Address Resolution To: ipv6@ietf.org Content-Type: multipart/alternative; boundary="000000000000ff4dcc05a51e2ed6" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 07:45:45 -0000 --000000000000ff4dcc05a51e2ed6 Content-Type: text/plain; charset="UTF-8" Fixed the typo in the RFC number below. Any thoughts? Some quick changes from my side shows connection setup times for client to accessory acting as WiFi AP over v6 LLA that gets triggered right after joining it, from ~2 seconds to a tens of milliseconds. On Sun, May 3, 2020 at 12:38 AM prabhakar lakhera < prabhakar.lakhera@gmail.com> wrote: > I have to correct myself here. > > RFC 4861 does mandate sending SLLAO for multicast NS (which would be the > case for address resolution here) and that does make sense. > While it is definitely desired, I am not sure how can we resolve the > stated issue below without relaxing that requirement. > > One could modify the requirement that multicast NS with source that is > preferred MUST send SLLAO. > And RFC 7527 4429 could relax the requirement and allow for sending > multicast NS for address resolution with optimistic address which MUST not > include SLLAO. > > It does imply that for the scenario below, responding to such multicast NS > with an unicast NA would in turn trigger another address resolution but > that is not very different from when unicast NS may miss SLLAO and the > target doesn't have NS's source entry in its neighbor cache. > > It would still result in establishing the data path faster than waiting > for DAD to complete. > > I am not sure, how else it could be solved other than a more complicated > work around of requiring such APs to advertise RA with SLLAOs even when > they are not providing any IPv6 kind of routing. > > On Tue, Apr 28, 2020 at 6:26 PM prabhakar lakhera < > prabhakar.lakhera@gmail.com> wrote: > >> Hi, >>> >>> Wanted to check if this behavior outlined in RFC 7527 is too restrictive. >>> >>> https://www.rfc-editor.org/rfc/rfc4429.html#section-3.2 >>> >>> Specifically: >>> >>> * (modifies section 7.2.2 ) A node MUST NOT use an Optimistic Address >>> as the source address of a Neighbor Solicitation. >>> >>> >>> The reasoning is detailed here: >>> >>> https://www.rfc-editor.org/rfc/rfc4429.html#section-2.2 >>> >>> " In order to avoid interference, it is important that an Optimistic Node >>> does not send any messages from an Optimistic Address >>> that will override its neighbors' Neighbor Cache (NC) entries for the >>> address it is trying to configure: doing so would disrupt the >>> rightful owner of the address in the case of a collision." >>> >>> >>> It then goes on to list the following: >>> >>> >>> * Never sending Neighbor Solicitations from an Optimistic Address. >>> NSes include a Source Link-Layer Address Option (SLLAO), which >>> may cause Neighbor Cache disruption. NSes sent as part of DAD >>> are sent from the unspecified address, without a SLLAO. >>> >>> >>> That seems somewhat limiting. >>> >>> >>> Take the scenario of a client device connecting to another device that acts as an Access point without >>> >>> really providing routing (say a thermal camera device, android auto/car play head unit or some other smart device). >>> >>> >>> Right now, this would be the sequence: >>> >>> >>> 1. Interface comes up >>> >>> 2. Client attached to device acting as WiFi access point. >>> >>> 3. Both sides configure LLA pretty quickly. >>> >>> 4. Client uses multicast service discovery to get the LLA endpoint of the device. >>> >>> 5. Client attempts connect to the device's endpoint. Optimistic DAD implies, the address can be used. >>> >>> 6. Outgoing TCP SYN from client will trigger address resolution, and it will be queued pending address resolution completion. >>> >>> 7. Even though client LLA is optimistic, because it is the only address available and the device isn't sending RA with SLLAO or NS, >>> >>> the neighbor cache entry at Client for Device would stay in INCOMPLETE state and no NS will be sent out from client, till address >>> >>> moves from optimistic to preferred. >>> >>> 8. 7 Implies a wait time of DAD attempts * DAD interval >>> >>> >>> That runs in seconds and that delay is visible to user. >>> >>> >>> Given that source link layer information is optional in NS, wouldn't just mandating that SLLAO doesn't get sent in NS from client, >>> >>> be enough to not cause any disruptions rather than not allowing NS to be sent at all? >>> >>> >>> Or may be I am missing something here. Looking forward to hear some feedback on this. >>> >>> >>> Thanks! >>> >>> >>> Prabhakar >>> >>> >>> --000000000000ff4dcc05a51e2ed6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, May 8, 2020 at 12:16 PM Andrew Als= ton <Andrew.Alston@li= quidtelecom.com> wrote:

I do find it kinda bizarre that= one vendor or an individual would jump to a conclusion and make statements= about what another one desires =E2=80=93 surely it is up to the vendor tha= t desires something to publicly state so and not for someone else to make statements= on their behalf?

=C2=A0

I mean =E2=80=93 let=E2=80=99s = be clear =E2=80=93 I have written a partial SRv6 / SRv6-NP implementation i= nto our DPDK lab testing stack =E2=80=93 I did it to verify certain things = =E2=80=93 the only thing it further convinced me =C2=A0of is that I will never run this in production =E2=80=93 in a mil= lion years =E2=80=93 and I=E2=80=99d be rather concerned if someone went ou= t there and said on the basis of the fact that I chose to test something = =E2=80=93 I suddenly supported or liked it.=C2=A0 What that=E2=80=99s effec= tively saying is =E2=80=93 to test something is to support it =E2=80=93 that=E2=80=99s n= ot the case.=C2=A0 It=E2=80=99s similar to the line that I was given that b= ecause I signed a blue sheet in Singapore and didn=E2=80=99t stand up at th= e microphone and publically object to something at the time =E2=80=93 some = how my signature on the blue sheet indicated my acceptance and support of the issue in ques= tion.=C2=A0

=C2=A0

(To quote that)

=C2=A0

P= C2: The comment started because in the draft we had an example that was ass= igning A:1::/32 as loopback interface for a router. This is wrong (prefix l= ength, documentation prefix,).

T= his was fixed in revision 2 of the WG draft, published in September 19= th 2019. The closure of this comment was presented by me personally i= n IETF Singapore. Please refer to the slides. In Singapore you were present (signed blue sheet) and did not had = any comment about such closure.

= =C2=A0

= =C2=A0

T= his is interesting =E2=80=93 so firstly =E2=80=93 let me state that because= I was present in a meeting and signed a blue sheet to say I was there =E2= =80=93 in no way indicates that I forgo the right to object after the meeting =E2=80=93 and last I checked, signatures on a blue sheet are t= here to track attendance, not to track consensus.<= /p>

=C2=A0<= /i>

=C2=A0

So =E2=80=93 can I make a humbl= e request that we let people speak for themselves about what they actively = support and want rather than trying to speak for others to bolster our case= ?=C2=A0 Because if the case is so weak that we need to make claims on behalf of others =E2= =80=93 then there is no case at all.

=C2=A0

Thanks

=C2=A0

Andrew

--000000000000532d6705a5208766-- From nobody Fri May 8 03:56:43 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0CD3A09E3 for ; Fri, 8 May 2020 03:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 MKSP-BrRjc5K for ; Fri, 8 May 2020 03:56:35 -0700 (PDT) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [207.82.80.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7855E3A09E1 for <6man@ietf.org>; Fri, 8 May 2020 03:56:34 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp2052.outbound.protection.outlook.com [104.47.2.52]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-92-rNXULGwjP5ezaPVWT3QDVQ-1; Fri, 08 May 2020 11:56:29 +0100 X-MC-Unique: rNXULGwjP5ezaPVWT3QDVQ-1 Received: from AM6PR03MB5047.eurprd03.prod.outlook.com (2603:10a6:20b:89::13) by AM6PR03MB4679.eurprd03.prod.outlook.com (2603:10a6:20b:d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26; Fri, 8 May 2020 10:56:25 +0000 Received: from AM6PR03MB5047.eurprd03.prod.outlook.com ([fe80::8081:95b4:8a9d:e05d]) by AM6PR03MB5047.eurprd03.prod.outlook.com ([fe80::8081:95b4:8a9d:e05d%6]) with mapi id 15.20.2979.030; Fri, 8 May 2020 10:56:25 +0000 From: Andrew Alston To: Robert Raszuk CC: Ron Bonica , "Darren Dukes (ddukes)" , Krzysztof Szarkowicz , 6man <6man@ietf.org> Subject: RE: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AQHWI58t0MrEgFbBRG+Eev5I1WHYlaia/q4AgAHXnICAAAry0IABGRowgAAGnQCAAAB1UA== Date: Fri, 8 May 2020 10:56:25 +0000 Message-ID: References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2c0f:fe40:3:2:8127:1b33:8af4:f0ec] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 19ef884d-3f52-4ca1-85dc-08d7f33e73e3 x-ms-traffictypediagnostic: AM6PR03MB4679: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 039735BC4E x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qbq2s66uDaWvkO0GSHo0oCH3Uocdxc9z9TxXZJ6FccCeWG9PZNbraEJh2KEL3mM8cTvExuEbsvY8gKDmx5yCiyHTMZ464K/I+dT0JHBfzWy56osAr8krXIErRHqhM9o4IQt6WL8SwUPsQD68ke47cykA/O87znmhXyI8Xz4X64LsTmWQf17CkZxJo0eB4FyyX4O8p0LoZsQiPyQ6Hr2UU9S9kou7B2bxovGlzs+LrWa9MRovhmRLZWBVHb7Hp+E6J49af4URTuLHsS5m4id47O3GKnVuVKxY8XUoDBz+UxxdKJPyOisuwvWpz7euDDLUI7ci3Guge3zugI3OFa6dQfcrDSMzbKW/Y8KiVwi+SHBDyxU4+7hARx1zRdVQR+FcDOAsg4xwytydp7xyUHZ+b3BmvVObueez3Py5Nur0wJM1Pd6idLjKaoVPn+Dy6d7wCReRqqj3zRspkfQy5H36lhiulSJrQxlJIjTh6wca4NSlLjA0cp6wyrcFv96+zQzLFgCGWM1VBJ1g+WrkkBE1vw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR03MB5047.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(396003)(366004)(136003)(33430700001)(66946007)(7116003)(478600001)(3480700007)(55016002)(66574014)(66556008)(33656002)(64756008)(71200400001)(76116006)(66446008)(83300400001)(52536014)(5660300002)(2906002)(83290400001)(83310400001)(83320400001)(83280400001)(7696005)(86362001)(9686003)(186003)(4326008)(66476007)(53546011)(6916009)(33440700001)(6506007)(54906003)(8676002)(316002)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: EyxUFeKlK7R3NhGQybbMNCC7NJNhD8FZlaSaMB4133/UWaJ5RRMGFDZRsuTcX0P16Su0NhOArsnqiGR2fPMg5CzPrNhGC46oMnKNXxq+jW0+HZLeeQMbH7MRUnGNsVYBg8dyT518quyfa+Egjl9uBP/H8cMD/IfKExNjJWcbLnw7nll8ImJLEPbbDP7TU2c6S/T03nBVHBLtgmalzdaRdw5Ra4Ucku8VSdpSVl2SNhGJyKeZfbzyX+oue/6muVPQBATXQ5Y69RLbrsN0fgEIVUEZM58a38iOkUggAABo/983MUP86t2YnWUG7/chAQ1mJxmurh/hi20f4xzJYx1k7iLzoNc9MnSEwJ6T3SSNWVXFotXr3ypg4jBQ0sHxYl7AguBJsqccWGQp9fGIFSQK9zHjZb7AXHRs/bZNQoN5lu18m6gWtW8cJWg/EWGvAiAmaoLUZcTel44t5B8JCKd8F9ltTI7xlr887V3zwuDuC1XYeaRTDzJnGh6fDzwWDF0bZ1q56eBAWKkAadRR6BPgYaEPYU3dhlxHoQNExyIwjgI= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19ef884d-3f52-4ca1-85dc-08d7f33e73e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 10:56:25.2917 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: awz7yjDAtM7Mrv+RZgrveyCBWXVeJ1SnYI17SpKJ3mk1wuNK9FxCm5Q15Kk+3W+yLdBOnFW2+FYLjkalLHeOqAIEpidpg1I+HkqmoeQjYJo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR03MB4679 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Type: multipart/alternative; boundary="_000_AM6PR03MB5047FAD411DC48034B178494EEA20AM6PR03MB5047eurp_" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 10:56:40 -0000 --_000_AM6PR03MB5047FAD411DC48034B178494EEA20AM6PR03MB5047eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpBY3R1YWxseSDigJMgaXQgcHJvdmVzIHByZWNpc2VseSBub3RoaW5nIHVudGls IHRoZXkgc3RhdGUgdGhlaXIgbW90aXZhdGlvbnMg4oCTIGFuZCB3ZSBoYXZlIG5vIHJpZ2h0IHRv IHJlYWQgbW90aXZhdGlvbnMgaW50byBpdC4gIFdlIGNhbiBhc2sgdGhlbSB3aHkgdGhleSBkaWQg aXQg4oCTIHdlIGNhbm5vdCBhc3N1bWUgYW5kIG5vciBkb2VzIGFueW9uZSBoYXZlIHRoZSByaWdo dCB0byBtYWtlIHN0YXRlbWVudHMgYWJvdXQgd2h5IHRoZXkgY2hvc2UgdG8gZG8gc29tZXRoaW5n IG91dHNpZGUgb2Ygc29tZW9uZSBlbHNlLg0KDQpUaGUgdHdpc3Rpbmcgb2Ygd29yZHMgdGhhdCBJ IGhhdmUgc2VlbiBvZiBsYXRlIGhhcyByZWFsbHkgZGlzdHVyYmVkIG1lLiAgQW5vdGhlciBjbGFz c2ljIGNhc2UgaW4gcG9pbnQgd2FzIHdoZXJlIGl0IHdhcyBjbGFpbWVkIGJ5IGFub3RoZXIgb3Bw b25lbnQgb2YgYSBkcmFmdCBzdGF0ZWQgdGhlIG5lZWQgZm9yIGFyY2hpdGVjdHVyYWwgZG9jdW1l bnRzLiAgSW4gZmFjdCB3aGF0IGhhZCBiZWVuIHN0YXRlZCB3YXMgdmVyeSBjbGVhciB0aGF0IHRo ZSBhcHBsaWNhdGlvbnMgVVNJTkcgdGhlIHByb3RvY29sIG5lZWRlZCBhcmNoaXRlY3R1cmFsIGRy YWZ0cyBhbmQgdGhpcyB3YXMgbWVyZWx5IGEgYnVpbGRpbmcgYmxvY2sgKGFuZCBiZWZvcmUgSSB3 cml0ZSB0aGlzLCBJIHZlcmlmaWVkIHZlcnkgY2xlYXIgdGhhdCB3YXMgd2hhdCB3YXMgb3JpZ2lu YWxseSBzYWlkLCB3aXRoIHRoZSBpbmRpdmlkdWFsIHN0YXRpbmcgaXQpLiAgTXkgcG9pbnQgaGVy ZSBpcyDigJMgdGhlIElFVEYgc2F5cyDigJMgZXZlcnkgcGVyc29uIHdobyBzdGVwcyB1cyBpcyBy ZXByZXNlbnRpbmcgdGhlbXNlbHZlcyBhcyBhbiBpbmRpdmlkdWFsLiAgSXQgaXMgbm90IGZvciB1 cyB0byBhc2NyaWJlIG1vdGl2YXRpb25zIHRvIG90aGVycyBhbmQgdGhlbiBnbyBmb3J3YXJkIGFu ZCBtYWtlIGNsYWltcyBhYm91dCBvdGhlciBwZW9wbGVzIG1vdGl2YXRpb25zLiAgTGV0IHVzIG1h a2Ugb3VyIGNhc2Ugb24gb3VyIG93biB0ZWNobmljYWwgZ3JvdW5kcy4NCg0KSSBwb2ludCBvdXQg dGhhdCB3aXRoaW4gdGhlIElFVEYg4oCTIGVhY2ggcGVyc29uIGlzIG1lYW50IHRvIHJlcHJlc2Vu dCB0aGVtc2VsdmVzIOKAkyBhbmQgc3RhdGVtZW50cyB0aGF0IGltcGx5IG1vdGl2YXRpb25zIG9m IG90aGVycyB0byBib2xzdGVyIGEgY2FzZSBpbiBteSB2aWV3LCBkbyBub3RoaW5nIG1vcmUgdGhh biB3ZWFrZW4gdGhlIGFyZ3VtZW50IG9mIHRob3NlIG1ha2luZyB0aGVtIOKAkyBiZWNhdXNlIGlm IHRoZSBhcmd1bWVudCBpcyBzdHJvbmcg4oCTIHRoZW4gbGV0IGl0IGJlIG1hZGUgb24gdGVjaG5p Y2FsIGdyb3VuZHMg4oCTIG5vdCBvbiB0aGUgYWN0aW9ucyBvZiBvdGhlcnMgd2hvIGhhdmUgbm90 IG1hZGUgc3RhdGVtZW50cyBhYm91dCB0aGVpciBvd24gbW90aXZhdGlvbnMuDQoNCkFuZHJldw0K DQpGcm9tOiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4NClNlbnQ6IEZyaWRheSwg OCBNYXkgMjAyMCAxMzozMw0KVG86IEFuZHJldyBBbHN0b24gPEFuZHJldy5BbHN0b25AbGlxdWlk dGVsZWNvbS5jb20+DQpDYzogUm9uIEJvbmljYSA8cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJj LmlldGYub3JnPjsgRGFycmVuIER1a2VzIChkZHVrZXMpIDxkZHVrZXM9NDBjaXNjby5jb21AZG1h cmMuaWV0Zi5vcmc+OyBLcnp5c3p0b2YgU3phcmtvd2ljeiA8a3N6YXJrb3dpY3pAZ21haWwuY29t PjsgNm1hbiA8Nm1hbkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBSb3V0aW5nIEhlYWRlciBJbnNl cnRpb24NCg0KDQpIZXkgQW5kcmV3LA0KDQpJIGRvbid0IHRoaW5rIHRoZSBwb2ludCBpcyBvbiB3 aGF0IG9uZSB2ZW5kb3IgZGVzaXJlcyBvciBsaWtlcy4gVGhlIHBvaW50IGlzIHRoYXQgdGhleSBp bnRlcm5hbGx5IGNvbW1pdHRlZCBkZXZlbG9wbWVudCByZXNvdXJjZXMgdG8gZGVsaXZlciB0aGlz IGZ1bmN0aW9uYWxpdHkuIFRoZXkgYWxzbyBhc2tlZCBvbmUgb2YgdGhlaXIgdG9wIHRhbGVudGVk IFRNRSBLcnp5c2llayB0byBnbyBhbmQgZGVtbyBpdC4gSXQgY2FycmllcyBhIG1lc3NhZ2UuIEFu ZCBhbGwgWmFmYXIgYW5kIG90aGVycyBkaWQgd2FzIGp1c3Qgc2hhcmluZyB0aGF0IG1lc3NhZ2Uu DQoNCkl0IHJlYWxseSBkb2VzIG5vdCBtYXR0ZXIgdGhhdCBtdWNoIFJvbiBoaW1zZWxmIG9yIG9u IGJlaGFsZiBvZiBoaXMgY29tcGFueSBjYW4ganVtcCBvbiB0aGUgbGlzdHMgc3RhdGluZyB0aGF0 IGhlIGRvZXMgbm90IGxpa2UgaXQuIEV2ZW4gaWYgSnVuaXBlciBtYXJrZXRpbmcgd2lsbCBub3Qg cHVzaCBpdCAtIGV2ZW4gaWYgdGhleSBkZXZlbG9wIG5leHQgY2FydG9vbiBtb2NraW5nIGl0IC0g dGhleSB3aWxsIHN0aWxsIGxpa2VseSBjaGVjayBtYXJrIHN1cHBvcnQgdGFnIG9uIHRoZSBSRlBz Lg0KDQpBbGwgdGhhdCBwcm92ZXMgdGhhdCBTUkggaW5zZXJ0aW9uIGlzIGEgdXNlZnVsIGZlYXR1 cmUgdG8gY3VzdG9tZXJzLiBBbmQgdGhhdCdzIGFsbCB3aGF0IG1hdHRlcnMgdG8gc29tZSBJRVRG IGRlY2lzaW9ucyBhcyBwYXJ0IG9mIHRoYXQgaXMgY29tbXVuaXR5IG5lZWRzIGFuZCBzdXBwb3J0 IGZvciBleHRlbnNpb25zIHVuZGVyIHN0YW5kYXJkaXphdGlvbi4NCg0KQmVzdCwNClJvYmVydC4N Cg0KDQpPbiBGcmksIE1heSA4LCAyMDIwIGF0IDEyOjE2IFBNIEFuZHJldyBBbHN0b24gPEFuZHJl dy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVs ZWNvbS5jb20+PiB3cm90ZToNCkkgZG8gZmluZCBpdCBraW5kYSBiaXphcnJlIHRoYXQgb25lIHZl bmRvciBvciBhbiBpbmRpdmlkdWFsIHdvdWxkIGp1bXAgdG8gYSBjb25jbHVzaW9uIGFuZCBtYWtl IHN0YXRlbWVudHMgYWJvdXQgd2hhdCBhbm90aGVyIG9uZSBkZXNpcmVzIOKAkyBzdXJlbHkgaXQg aXMgdXAgdG8gdGhlIHZlbmRvciB0aGF0IGRlc2lyZXMgc29tZXRoaW5nIHRvIHB1YmxpY2x5IHN0 YXRlIHNvIGFuZCBub3QgZm9yIHNvbWVvbmUgZWxzZSB0byBtYWtlIHN0YXRlbWVudHMgb24gdGhl aXIgYmVoYWxmPw0KDQpJIG1lYW4g4oCTIGxldOKAmXMgYmUgY2xlYXIg4oCTIEkgaGF2ZSB3cml0 dGVuIGEgcGFydGlhbCBTUnY2IC8gU1J2Ni1OUCBpbXBsZW1lbnRhdGlvbiBpbnRvIG91ciBEUERL IGxhYiB0ZXN0aW5nIHN0YWNrIOKAkyBJIGRpZCBpdCB0byB2ZXJpZnkgY2VydGFpbiB0aGluZ3Mg 4oCTIHRoZSBvbmx5IHRoaW5nIGl0IGZ1cnRoZXIgY29udmluY2VkIG1lICBvZiBpcyB0aGF0IEkg d2lsbCBuZXZlciBydW4gdGhpcyBpbiBwcm9kdWN0aW9uIOKAkyBpbiBhIG1pbGxpb24geWVhcnMg 4oCTIGFuZCBJ4oCZZCBiZSByYXRoZXIgY29uY2VybmVkIGlmIHNvbWVvbmUgd2VudCBvdXQgdGhl cmUgYW5kIHNhaWQgb24gdGhlIGJhc2lzIG9mIHRoZSBmYWN0IHRoYXQgSSBjaG9zZSB0byB0ZXN0 IHNvbWV0aGluZyDigJMgSSBzdWRkZW5seSBzdXBwb3J0ZWQgb3IgbGlrZWQgaXQuICBXaGF0IHRo YXTigJlzIGVmZmVjdGl2ZWx5IHNheWluZyBpcyDigJMgdG8gdGVzdCBzb21ldGhpbmcgaXMgdG8g c3VwcG9ydCBpdCDigJMgdGhhdOKAmXMgbm90IHRoZSBjYXNlLiAgSXTigJlzIHNpbWlsYXIgdG8g dGhlIGxpbmUgdGhhdCBJIHdhcyBnaXZlbiB0aGF0IGJlY2F1c2UgSSBzaWduZWQgYSBibHVlIHNo ZWV0IGluIFNpbmdhcG9yZSBhbmQgZGlkbuKAmXQgc3RhbmQgdXAgYXQgdGhlIG1pY3JvcGhvbmUg YW5kIHB1YmxpY2FsbHkgb2JqZWN0IHRvIHNvbWV0aGluZyBhdCB0aGUgdGltZSDigJMgc29tZSBo b3cgbXkgc2lnbmF0dXJlIG9uIHRoZSBibHVlIHNoZWV0IGluZGljYXRlZCBteSBhY2NlcHRhbmNl IGFuZCBzdXBwb3J0IG9mIHRoZSBpc3N1ZSBpbiBxdWVzdGlvbi4NCg0KKFRvIHF1b3RlIHRoYXQp DQoNClBDMjogVGhlIGNvbW1lbnQgc3RhcnRlZCBiZWNhdXNlIGluIHRoZSBkcmFmdCB3ZSBoYWQg YW4gZXhhbXBsZSB0aGF0IHdhcyBhc3NpZ25pbmcgQToxOjovMzIgYXMgbG9vcGJhY2sgaW50ZXJm YWNlIGZvciBhIHJvdXRlci4gVGhpcyBpcyB3cm9uZyAocHJlZml4IGxlbmd0aCwgZG9jdW1lbnRh dGlvbiBwcmVmaXgsKS4NClRoaXMgd2FzIGZpeGVkIGluIHJldmlzaW9uIDIgb2YgdGhlIFdHIGRy YWZ0LCBwdWJsaXNoZWQgaW4gU2VwdGVtYmVyIDE5dGggMjAxOS4gVGhlIGNsb3N1cmUgb2YgdGhp cyBjb21tZW50IHdhcyBwcmVzZW50ZWQgYnkgbWUgcGVyc29uYWxseSBpbiBJRVRGIFNpbmdhcG9y ZS4gUGxlYXNlIHJlZmVyIHRvIHRoZSBzbGlkZXMuIEluIFNpbmdhcG9yZSB5b3Ugd2VyZSBwcmVz ZW50IChzaWduZWQgYmx1ZSBzaGVldCkgYW5kIGRpZCBub3QgaGFkIGFueSBjb21tZW50IGFib3V0 IHN1Y2ggY2xvc3VyZS4NCg0KDQpUaGlzIGlzIGludGVyZXN0aW5nIOKAkyBzbyBmaXJzdGx5IOKA kyBsZXQgbWUgc3RhdGUgdGhhdCBiZWNhdXNlIEkgd2FzIHByZXNlbnQgaW4gYSBtZWV0aW5nIGFu ZCBzaWduZWQgYSBibHVlIHNoZWV0IHRvIHNheSBJIHdhcyB0aGVyZSDigJMgaW4gbm8gd2F5IGlu ZGljYXRlcyB0aGF0IEkgZm9yZ28gdGhlIHJpZ2h0IHRvIG9iamVjdCBhZnRlciB0aGUgbWVldGlu ZyDigJMgYW5kIGxhc3QgSSBjaGVja2VkLCBzaWduYXR1cmVzIG9uIGEgYmx1ZSBzaGVldCBhcmUg dGhlcmUgdG8gdHJhY2sgYXR0ZW5kYW5jZSwgbm90IHRvIHRyYWNrIGNvbnNlbnN1cy4NCg0KDQpT byDigJMgY2FuIEkgbWFrZSBhIGh1bWJsZSByZXF1ZXN0IHRoYXQgd2UgbGV0IHBlb3BsZSBzcGVh ayBmb3IgdGhlbXNlbHZlcyBhYm91dCB3aGF0IHRoZXkgYWN0aXZlbHkgc3VwcG9ydCBhbmQgd2Fu dCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gc3BlYWsgZm9yIG90aGVycyB0byBib2xzdGVyIG91ciBj YXNlPyAgQmVjYXVzZSBpZiB0aGUgY2FzZSBpcyBzbyB3ZWFrIHRoYXQgd2UgbmVlZCB0byBtYWtl IGNsYWltcyBvbiBiZWhhbGYgb2Ygb3RoZXJzIOKAkyB0aGVuIHRoZXJlIGlzIG5vIGNhc2UgYXQg YWxsLg0KDQpUaGFua3MNCg0KQW5kcmV3DQo= --_000_AM6PR03MB5047FAD411DC48034B178494EEA20AM6PR03MB5047eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9ImVuLUtFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Sb2JlcnQsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+QWN0dWFsbHkg4oCTIGl0IHByb3ZlcyBwcmVjaXNlbHkgbm90 aGluZyB1bnRpbCB0aGV5IHN0YXRlIHRoZWlyIG1vdGl2YXRpb25zIOKAkyBhbmQgd2UgaGF2ZSBu byByaWdodCB0byByZWFkIG1vdGl2YXRpb25zIGludG8gaXQuJm5ic3A7IFdlIGNhbiBhc2sgdGhl bSB3aHkgdGhleSBkaWQgaXQg4oCTIHdlIGNhbm5vdCBhc3N1bWUgYW5kDQogbm9yIGRvZXMgYW55 b25lIGhhdmUgdGhlIHJpZ2h0IHRvIG1ha2Ugc3RhdGVtZW50cyBhYm91dCB3aHkgdGhleSBjaG9z ZSB0byBkbyBzb21ldGhpbmcgb3V0c2lkZSBvZiBzb21lb25lIGVsc2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+VGhlIHR3aXN0aW5nIG9mIHdvcmRzIHRoYXQgSSBoYXZlIHNlZW4g b2YgbGF0ZSBoYXMgcmVhbGx5IGRpc3R1cmJlZCBtZS4mbmJzcDsgQW5vdGhlciBjbGFzc2ljIGNh c2UgaW4gcG9pbnQgd2FzIHdoZXJlIGl0IHdhcyBjbGFpbWVkIGJ5IGFub3RoZXIgb3Bwb25lbnQg b2YgYSBkcmFmdCBzdGF0ZWQgdGhlIG5lZWQgZm9yIGFyY2hpdGVjdHVyYWwNCiBkb2N1bWVudHMu Jm5ic3A7IEluIGZhY3Qgd2hhdCBoYWQgYmVlbiBzdGF0ZWQgd2FzIHZlcnkgY2xlYXIgdGhhdCB0 aGUgYXBwbGljYXRpb25zIFVTSU5HIHRoZSBwcm90b2NvbCBuZWVkZWQgYXJjaGl0ZWN0dXJhbCBk cmFmdHMgYW5kIHRoaXMgd2FzIG1lcmVseSBhIGJ1aWxkaW5nIGJsb2NrIChhbmQgYmVmb3JlIEkg d3JpdGUgdGhpcywgSSB2ZXJpZmllZCB2ZXJ5IGNsZWFyIHRoYXQgd2FzIHdoYXQgd2FzIG9yaWdp bmFsbHkgc2FpZCwgd2l0aCB0aGUgaW5kaXZpZHVhbA0KIHN0YXRpbmcgaXQpLiZuYnNwOyBNeSBw b2ludCBoZXJlIGlzIOKAkyB0aGUgSUVURiBzYXlzIOKAkyBldmVyeSBwZXJzb24gd2hvIHN0ZXBz IHVzIGlzIHJlcHJlc2VudGluZyB0aGVtc2VsdmVzIGFzIGFuIGluZGl2aWR1YWwuJm5ic3A7IEl0 IGlzIG5vdCBmb3IgdXMgdG8gYXNjcmliZSBtb3RpdmF0aW9ucyB0byBvdGhlcnMgYW5kIHRoZW4g Z28gZm9yd2FyZCBhbmQgbWFrZSBjbGFpbXMgYWJvdXQgb3RoZXIgcGVvcGxlcyBtb3RpdmF0aW9u cy4mbmJzcDsgTGV0IHVzIG1ha2Ugb3VyDQogY2FzZSBvbiBvdXIgb3duIHRlY2huaWNhbCBncm91 bmRzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJlbi1LRSIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHBvaW50IG91dCB0aGF0IHdp dGhpbiB0aGUgSUVURiDigJMgZWFjaCBwZXJzb24gaXMgbWVhbnQgdG8gcmVwcmVzZW50IHRoZW1z ZWx2ZXMg4oCTIGFuZCBzdGF0ZW1lbnRzIHRoYXQgaW1wbHkgbW90aXZhdGlvbnMgb2Ygb3RoZXJz IHRvIGJvbHN0ZXIgYSBjYXNlIGluIG15IHZpZXcsIGRvIG5vdGhpbmcgbW9yZSB0aGFuIHdlYWtl bg0KIHRoZSBhcmd1bWVudCBvZiB0aG9zZSBtYWtpbmcgdGhlbSDigJMgYmVjYXVzZSBpZiB0aGUg YXJndW1lbnQgaXMgc3Ryb25nIOKAkyB0aGVuIGxldCBpdCBiZSBtYWRlIG9uIHRlY2huaWNhbCBn cm91bmRzIOKAkyBub3Qgb24gdGhlIGFjdGlvbnMgb2Ygb3RoZXJzIHdobyBoYXZlIG5vdCBtYWRl IHN0YXRlbWVudHMgYWJvdXQgdGhlaXIgb3duIG1vdGl2YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkFuZHJldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBS b2JlcnQgUmFzenVrICZsdDtyb2JlcnRAcmFzenVrLm5ldCZndDsNCjxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIDggTWF5IDIwMjAgMTM6MzM8YnI+DQo8Yj5Ubzo8L2I+IEFuZHJldyBBbHN0b24g Jmx0O0FuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBS b24gQm9uaWNhICZsdDtyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBE YXJyZW4gRHVrZXMgKGRkdWtlcykgJmx0O2RkdWtlcz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9y ZyZndDs7IEtyenlzenRvZiBTemFya293aWN6ICZsdDtrc3phcmtvd2ljekBnbWFpbC5jb20mZ3Q7 OyA2bWFuICZsdDs2bWFuQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUm91 dGluZyBIZWFkZXIgSW5zZXJ0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IZXkgQW5kcmV3LDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSBkb24ndCB0aGluayB0 aGUgcG9pbnQgaXMgb24gd2hhdCBvbmUgdmVuZG9yIGRlc2lyZXMgb3IgbGlrZXMuIFRoZSBwb2lu dCBpcyB0aGF0IHRoZXkgaW50ZXJuYWxseSBjb21taXR0ZWQmbmJzcDtkZXZlbG9wbWVudCByZXNv dXJjZXMgdG8gZGVsaXZlciB0aGlzIGZ1bmN0aW9uYWxpdHkuIFRoZXkgYWxzbyBhc2tlZCBvbmUg b2YgdGhlaXIgdG9wIHRhbGVudGVkIFRNRSZuYnNwO0tyenlzaWVrDQogdG8gZ28gYW5kIGRlbW8g aXQuIEl0IGNhcnJpZXMgYSBtZXNzYWdlLiBBbmQgYWxsIFphZmFyIGFuZCBvdGhlcnMgZGlkIHdh cyBqdXN0IHNoYXJpbmcgdGhhdCBtZXNzYWdlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JdCByZWFsbHkgZG9lcyBub3QgbWF0dGVyIHRo YXQgbXVjaCBSb24gaGltc2VsZiBvciBvbiBiZWhhbGYgb2YgaGlzIGNvbXBhbnkgY2FuIGp1bXAg b24gdGhlIGxpc3RzIHN0YXRpbmcgdGhhdCBoZSZuYnNwO2RvZXMgbm90IGxpa2UmbmJzcDtpdC4g RXZlbiBpZiBKdW5pcGVyIG1hcmtldGluZyB3aWxsIG5vdCBwdXNoIGl0IC0gZXZlbiBpZiB0aGV5 Jm5ic3A7ZGV2ZWxvcCZuYnNwO25leHQgY2FydG9vbg0KIG1vY2tpbmcmbmJzcDtpdCAtIHRoZXkg d2lsbCBzdGlsbCBsaWtlbHkgY2hlY2sgbWFyayBzdXBwb3J0IHRhZyBvbiB0aGUgUkZQcy4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+ QWxsIHRoYXQgcHJvdmVzIHRoYXQgU1JIIGluc2VydGlvbiBpcyBhIHVzZWZ1bCBmZWF0dXJlIHRv Jm5ic3A7Y3VzdG9tZXJzLjwvYj4gQW5kIHRoYXQncyBhbGwgd2hhdCBtYXR0ZXJzIHRvIHNvbWUg SUVURiBkZWNpc2lvbnMgYXMgcGFydCBvZiB0aGF0IGlzIGNvbW11bml0eSBuZWVkcyBhbmQgc3Vw cG9ydCBmb3IgZXh0ZW5zaW9ucyB1bmRlciBzdGFuZGFyZGl6YXRpb24uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkJlc3QsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5Sb2JlcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gRnJpLCBNYXkgOCwgMjAy MCBhdCAxMjoxNiBQTSBBbmRyZXcgQWxzdG9uICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmV3LkFs c3RvbkBsaXF1aWR0ZWxlY29tLmNvbSI+QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFu IGxhbmc9IkVOLVVTIj5JIGRvIGZpbmQgaXQga2luZGEgYml6YXJyZSB0aGF0IG9uZSB2ZW5kb3Ig b3IgYW4gaW5kaXZpZHVhbCB3b3VsZCBqdW1wIHRvIGEgY29uY2x1c2lvbiBhbmQgbWFrZSBzdGF0 ZW1lbnRzIGFib3V0IHdoYXQgYW5vdGhlciBvbmUgZGVzaXJlcyDigJMgc3VyZWx5IGl0IGlzIHVw IHRvIHRoZSB2ZW5kb3IgdGhhdCBkZXNpcmVzIHNvbWV0aGluZyB0byBwdWJsaWNseSBzdGF0ZSBz byBhbmQgbm90IGZvciBzb21lb25lIGVsc2UNCiB0byBtYWtlIHN0YXRlbWVudHMgb24gdGhlaXIg YmVoYWxmPzwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIj5JIG1lYW4g4oCTIGxldOKAmXMgYmUgY2xlYXIg4oCTIEkgaGF2ZSB3cml0dGVu IGEgcGFydGlhbCBTUnY2IC8gU1J2Ni1OUCBpbXBsZW1lbnRhdGlvbiBpbnRvIG91ciBEUERLIGxh YiB0ZXN0aW5nIHN0YWNrIOKAkyBJIGRpZCBpdCB0byB2ZXJpZnkgY2VydGFpbiB0aGluZ3Mg4oCT IHRoZSBvbmx5IHRoaW5nIGl0IGZ1cnRoZXIgY29udmluY2VkIG1lICZuYnNwO29mIGlzIHRoYXQg SSB3aWxsIG5ldmVyIHJ1biB0aGlzIGluIHByb2R1Y3Rpb24NCiDigJMgaW4gYSBtaWxsaW9uIHll YXJzIOKAkyBhbmQgSeKAmWQgYmUgcmF0aGVyIGNvbmNlcm5lZCBpZiBzb21lb25lIHdlbnQgb3V0 IHRoZXJlIGFuZCBzYWlkIG9uIHRoZSBiYXNpcyBvZiB0aGUgZmFjdCB0aGF0IEkgY2hvc2UgdG8g dGVzdCBzb21ldGhpbmcg4oCTIEkgc3VkZGVubHkgc3VwcG9ydGVkIG9yIGxpa2VkIGl0LiZuYnNw OyBXaGF0IHRoYXTigJlzIGVmZmVjdGl2ZWx5IHNheWluZyBpcyDigJMgdG8gdGVzdCBzb21ldGhp bmcgaXMgdG8gc3VwcG9ydCBpdCDigJMgdGhhdOKAmXMNCiBub3QgdGhlIGNhc2UuJm5ic3A7IEl0 4oCZcyBzaW1pbGFyIHRvIHRoZSBsaW5lIHRoYXQgSSB3YXMgZ2l2ZW4gdGhhdCBiZWNhdXNlIEkg c2lnbmVkIGEgYmx1ZSBzaGVldCBpbiBTaW5nYXBvcmUgYW5kIGRpZG7igJl0IHN0YW5kIHVwIGF0 IHRoZSBtaWNyb3Bob25lIGFuZCBwdWJsaWNhbGx5IG9iamVjdCB0byBzb21ldGhpbmcgYXQgdGhl IHRpbWUg4oCTIHNvbWUgaG93IG15IHNpZ25hdHVyZSBvbiB0aGUgYmx1ZSBzaGVldCBpbmRpY2F0 ZWQgbXkgYWNjZXB0YW5jZQ0KIGFuZCBzdXBwb3J0IG9mIHRoZSBpc3N1ZSBpbiBxdWVzdGlvbi4m bmJzcDsgPC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiPihUbyBxdW90ZSB0aGF0KTwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBw dCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MTA4LjBwdCI+DQo8aT48c3BhbiBsYW5nPSJFTi1VUyI+UEMyOiBUaGUgY29tbWVudCBzdGFydGVk IGJlY2F1c2UgaW4gdGhlIGRyYWZ0IHdlIGhhZCBhbiBleGFtcGxlIHRoYXQgd2FzIGFzc2lnbmlu ZyBBOjE6Oi8zMiBhcyBsb29wYmFjayBpbnRlcmZhY2UgZm9yIGEgcm91dGVyLiBUaGlzIGlzIHdy b25nIChwcmVmaXggbGVuZ3RoLCBkb2N1bWVudGF0aW9uIHByZWZpeCwpLjwvc3Bhbj48L2k+PHNw YW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDoxMDguMHB0Ij4NCjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIHdh cyBmaXhlZCBpbiByZXZpc2lvbiAyIG9mIHRoZSBXRyBkcmFmdCwgcHVibGlzaGVkIGluIFNlcHRl bWJlciAxOTxzdXA+dGg8L3N1cD4gMjAxOS4gVGhlIGNsb3N1cmUgb2YgdGhpcyBjb21tZW50IHdh cyBwcmVzZW50ZWQgYnkgbWUgcGVyc29uYWxseSBpbiBJRVRGIFNpbmdhcG9yZS4gUGxlYXNlIHJl ZmVyIHRvIHRoZSBzbGlkZXMuIEluIFNpbmdhcG9yZSB5b3Ugd2VyZSBwcmVzZW50IChzaWduZWQN CiBibHVlIHNoZWV0KSBhbmQgZGlkIG5vdCBoYWQgYW55IGNvbW1lbnQgYWJvdXQgc3VjaCBjbG9z dXJlLjwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxMDguMHB0Ij4NCjxpPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9pPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4N CjxpPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9pPjxzcGFuIGxhbmc9ImVuLUtF Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6NzIuMHB0Ij4NCjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIGlzIGludGVyZXN0aW5nIOKA kyBzbyBmaXJzdGx5IOKAkyBsZXQgbWUgc3RhdGUgdGhhdCBiZWNhdXNlIEkgd2FzIHByZXNlbnQg aW4gYSBtZWV0aW5nIGFuZCBzaWduZWQgYSBibHVlIHNoZWV0IHRvIHNheSBJIHdhcyB0aGVyZSDi gJMgaW4gbm8gd2F5IGluZGljYXRlcyB0aGF0IEkgZm9yZ28gdGhlIHJpZ2h0IHRvIG9iamVjdCBh ZnRlciB0aGUgbWVldGluZyDigJMgYW5kIGxhc3QgSSBjaGVja2VkLCBzaWduYXR1cmVzDQogb24g YSBibHVlIHNoZWV0IGFyZSB0aGVyZSB0byB0cmFjayBhdHRlbmRhbmNlLCBub3QgdG8gdHJhY2sg Y29uc2Vuc3VzLjwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPGk+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4w cHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+U28g4oCTIGNhbiBJIG1ha2UgYSBodW1ibGUg cmVxdWVzdCB0aGF0IHdlIGxldCBwZW9wbGUgc3BlYWsgZm9yIHRoZW1zZWx2ZXMgYWJvdXQgd2hh dCB0aGV5IGFjdGl2ZWx5IHN1cHBvcnQgYW5kIHdhbnQgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIHNw ZWFrIGZvciBvdGhlcnMgdG8gYm9sc3RlciBvdXIgY2FzZT8mbmJzcDsgQmVjYXVzZSBpZiB0aGUg Y2FzZSBpcyBzbyB3ZWFrIHRoYXQgd2UgbmVlZCB0byBtYWtlIGNsYWltcyBvbg0KIGJlaGFsZiBv ZiBvdGhlcnMg4oCTIHRoZW4gdGhlcmUgaXMgbm8gY2FzZSBhdCBhbGwuPC9zcGFuPjxzcGFuIGxh bmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rczwvc3Bh bj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5B bmRyZXc8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_AM6PR03MB5047FAD411DC48034B178494EEA20AM6PR03MB5047eurp_-- From nobody Fri May 8 06:27:54 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E093A0AB2 for ; Fri, 8 May 2020 06:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=juniper.net header.b=s5Fgzu1n; dkim=pass (1024-bit key) header.d=juniper.net header.b=Cb0vJMos Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DvAJG0lykrg for ; Fri, 8 May 2020 06:27:48 -0700 (PDT) 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 80CB93A02C1 for <6man@ietf.org>; Fri, 8 May 2020 06:27:48 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 048DRkci017475; Fri, 8 May 2020 06:27:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=jx7CjroTC+khn1e319/kKXv+Rqp/IHHVUuEYklvoTu8=; b=s5Fgzu1nC3E2ek+29+qt+AKFhWoyha7vG17ztber5QOhbR09EZc3YCFwiN0twh3C+PEZ ItWjS7QlnjSd3KbpAxARMzRkbDjnsKbGi6tSy5O+I0W7DoGNeEoEhfhvlSoyhAmn7djL XTezWk+gh12qO7mxbYmbsGqkx0NZixCuzOR2egdFYKUF7kXwu4gaf1U83u+k1ppF5zoi 0F+vKDnW3oaU7hKbRtKO9s4jY2TA8vrsnq064LowcDPnu6K8bhQv7oLMQzhAaM6399Em e3sNhnJfplANDd/HSWhhfc+m2MRctSEQcxbprkn1K8ioY0Gy4WMweXcMtK8cHTaGh5KA wA== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2100.outbound.protection.outlook.com [104.47.70.100]) by mx0a-00273201.pphosted.com with ESMTP id 30w1tt0nj5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 May 2020 06:27:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VnHo1r20AGSLoKXp/YQmoKn0xwSZNw6g2IIlqKEpMB4aFMzDrCFliciedHj/D6qgCtLsoTXUKPxWhx406Qjmlw9z5+OrQTRAQSZnZ1cI03pA6aDd/uESXIf990ne+BYdJpRSXVzsnrF4n6hE87Z0zdVt3jUSnxwYgiOsLgFQcTjaC28X6x8R6r+L0JMJmnZjxWPiW7Q7l0lnFNwut52qQFqyIqQYm2V2cjZObnxDII5rMmE4GbpVHJ2sXAF9omB5fMDPBd9rSuyf59BZWMyB/lQdXAmYd4hjKt3PKOFrpgDnoVyn1SNK+Ffl8cqBACeJ9s7uvJ70iSviK2mQkl6M4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jx7CjroTC+khn1e319/kKXv+Rqp/IHHVUuEYklvoTu8=; b=Yo94y+y5cE//XebUAeSL71Be5hwF/iUTkTrG4F/+Hwu0ouGJ0cBDNf8Pq7CYWi4edKqSwYptk7j4n2tDh7KEx7jaB4pAcGoboQ98IhJ9wpz1tx00M0KUKxj+NjwWM9Oh1bzZSaTv/tbbwEmWB+so31ePsprMzVLNdYkBwT53hzODXDefkllx6GpGyvLeh9TjeHNIfLE8bbcGy8QALtsOV/M/y+LpISBBi2zmXbIqtekIJfEZgifIPg6QQKpAu4V2OZOM7WWITgkFjBwuTHNl24AszJNPsSx5ZW/ldwmVkxDddKl25XvJmWNmNtFOM0mmHUeYovtoX9yuildZt2cI/w== 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=jx7CjroTC+khn1e319/kKXv+Rqp/IHHVUuEYklvoTu8=; b=Cb0vJMos5hqxi7UV9c2/a5UDppQs7lFY7Fw4GvXsqO37RM1E5BqE0NDyrPyNvn/s6zkkvwWxs6cAuA69MfALBdtyjlOouK5QCGKdPmCE8kd9rz1tDovto5g6LFOk3hoVvgzqx0E8Uq/R9YGpNSn/abhGeB2JSwdjrRAFPw3YylE= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB6972.namprd05.prod.outlook.com (2603:10b6:5:1da::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.13; Fri, 8 May 2020 13:27:43 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.2979.028; Fri, 8 May 2020 13:27:42 +0000 From: Ron Bonica To: "EXT-Andrew.Alston@liquidtelecom.com" , Robert Raszuk CC: "Darren Dukes (ddukes)" , Krzysztof Szarkowicz , 6man <6man@ietf.org> Subject: RE: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AQHWI58t0MrEgFbBRG+Eev5I1WHYlaia/q4AgAHXnICAAAry0IABGRowgAAGnQCAAAB1UIAAK7KQ Date: Fri, 8 May 2020 13:27:42 +0000 Message-ID: References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> 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_SetDate=2020-05-08T13:27:39Z; 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=d6f30132-893a-4829-a0bf-5bcb370694dd; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action authentication-results: liquidtelecom.com; dkim=none (message not signed) header.d=none;liquidtelecom.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 04049982-7a82-4136-3487-08d7f3539611 x-ms-traffictypediagnostic: DM6PR05MB6972: x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 039735BC4E x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1aNIRE+uTUPEmrtGLMrYsqbXgVaqvJyPhaWXBVn8c+IeTZlfNLukHGtJR0/2xxXRaH0UqtOgEBHALZYw5l7YyEsWcItNzSoxoHEjcZbElFZKOCEbRqef0EhSPC3T12848aGXiPELaLK4rqrZJQ3lwbkXwaUPbpPP/nnIdmt+8gtgILAMt2eSNF1dSl7SIhDq3lsSvksXJIv2p1wCRMjLWwBFElNxJhgpq7JVYRW709RtOQydOpjL8hDp7zbBKUZdKZXb8VU32RUOQCCiDCr/8RPAUt0wI6vSuFD2/CpOplij7QH/xjp7k+5Qin5v4568kqSSvqK/cnbvejEb3azecKJEchIHD//XsPMNFFEhtB9sM9RgkZtjMq2q/Zk6jjYiqQWmG7fh8U5d76//34tY7++J7QIJdzzbmK7wIfYdJA7mBynOuRlS6i0WXMYdIyk0pRH/qu1lvBv5CmaUDJrpaqYR44hkQhdMBR5YnV+Ebj2gWOj/OUgMA4LVOvMFqNqUGQIxODDnIP/jJQhkv3aDVSqDXZE9tSXD0oyFGkoo1Nw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(136003)(366004)(39860400002)(376002)(33430700001)(8676002)(3480700007)(76116006)(66946007)(66476007)(66556008)(64756008)(66446008)(52536014)(33656002)(7116003)(33440700001)(83280400001)(478600001)(66574014)(83320400001)(83290400001)(83310400001)(83300400001)(8936002)(7696005)(26005)(186003)(6506007)(4326008)(53546011)(9686003)(316002)(55016002)(110136005)(54906003)(2906002)(86362001)(5660300002)(71200400001)(491001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 0zDEuNZs4Kfm/Q6d+TS8TaGGYDTUYHaHivT1PNKmJF6uc3J2dRQA78NqYv/pKG3bVfXERfunXqy5d4NF2yo/5Gs+NLsYYZx/vfS1Nk+beM/nKWPUC3BdETruWt6ANr4otkCppu24yGDL92C0sjMweUK6zxro6W721VGPs5F6+XrZyyS7RIs7Qwmi9UaxRPzu0LYMgWDJR4HM+6e5vxRWWbYQqUAZy23uomlzl1ayuirmY7fakyyoLeeWMpyfhVo+D8oiPualpHMx/QtzTfXdvi07Hn3cL7oVhcP8AiCvjQx/f3QOFC0k+PPDIyz1iD+xiZZyhGwFQXtWnuzsa3lTdgZ7urAXxQZNX28y3XppMwTk3bi0BlFZn5u2WUNh1vXh9hDil0XhSLpdy5JXr/0aMwNz6CQ2xzE8JWqbswZLIx0FoKbcn4lXI1fdBsc3H+JRsHnNiA/F4A/RIuyaouSvHVwwWDXtmIrid5dZcMe+6keAXMRDkwxy6ghHWu6z11s4 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB63485BA2D98671CD5DAF1263AEA20DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 04049982-7a82-4136-3487-08d7f3539611 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 13:27:42.0360 (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: rxlCNChd83YQolWJLMJu5g/K9YwYKuis2XLkOIoSgXMbdVj/XxCUXUPhzZBzZXmsJzApfySaxx0CnVAAEYwzCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB6972 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-08_13:2020-05-08, 2020-05-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 clxscore=1031 lowpriorityscore=0 mlxlogscore=999 mlxscore=0 adultscore=0 impostorscore=0 suspectscore=0 phishscore=0 spamscore=0 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005080119 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 13:27:52 -0000 --_000_DM6PR05MB63485BA2D98671CD5DAF1263AEA20DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Because my name and my company have been mentioned so many times in this th= read, I feel obliged to respond. Yet, I have no interest in mud-slinging. S= o, I will mention a few principles that guide Juniper employees when partic= ipating in the IETF: * IETF mailing lists are for technical discussion * Demonstrate factual and intellectual honesty * Treat all participants with respect * IETF mailing list are not for marketing * Never make a marketing or positioning statement on an IETF mailing= list * Never infer the intention or positioning of a competitor on an IET= F mailing list I consider all of the participants in this discussion to be good friends an= d I invite them to affirm these principles. And then, my friends, let us return to technical discussion. = Ron Juniper Business Use Only From: Andrew Alston Sent: Friday, May 8, 2020 6:56 AM To: Robert Raszuk Cc: Ron Bonica ; Darren Dukes (ddukes) ; Krzysztof Szarkowicz ; 6man <6man@ietf.org> Subject: RE: Routing Header Insertion [External Email. Be cautious of content] Robert, Actually - it proves precisely nothing until they state their motivations -= and we have no right to read motivations into it. We can ask them why the= y did it - we cannot assume and nor does anyone have the right to make stat= ements about why they chose to do something outside of someone else. The twisting of words that I have seen of late has really disturbed me. An= other classic case in point was where it was claimed by another opponent of= a draft stated the need for architectural documents. In fact what had bee= n stated was very clear that the applications USING the protocol needed arc= hitectural drafts and this was merely a building block (and before I write = this, I verified very clear that was what was originally said, with the ind= ividual stating it). My point here is - the IETF says - every person who s= teps us is representing themselves as an individual. It is not for us to a= scribe motivations to others and then go forward and make claims about othe= r peoples motivations. Let us make our case on our own technical grounds. I point out that within the IETF - each person is meant to represent themse= lves - and statements that imply motivations of others to bolster a case in= my view, do nothing more than weaken the argument of those making them - b= ecause if the argument is strong - then let it be made on technical grounds= - not on the actions of others who have not made statements about their ow= n motivations. Andrew From: Robert Raszuk > Sent: Friday, 8 May 2020 13:33 To: Andrew Alston > Cc: Ron Bonica >; Darren Dukes (ddukes) >; Krzysztof Szarko= wicz >; 6man <6man@ietf= .org> Subject: Re: Routing Header Insertion Hey Andrew, I don't think the point is on what one vendor desires or likes. The point i= s that they internally committed development resources to deliver this func= tionality. They also asked one of their top talented TME Krzysiek to go and= demo it. It carries a message. And all Zafar and others did was just shari= ng that message. It really does not matter that much Ron himself or on behalf of his company= can jump on the lists stating that he does not like it. Even if Juniper ma= rketing will not push it - even if they develop next cartoon mocking it - t= hey will still likely check mark support tag on the RFPs. All that proves that SRH insertion is a useful feature to customers. And th= at's all what matters to some IETF decisions as part of that is community n= eeds and support for extensions under standardization. Best, Robert. On Fri, May 8, 2020 at 12:16 PM Andrew Alston > wrote: I do find it kinda bizarre that one vendor or an individual would jump to a= conclusion and make statements about what another one desires - surely it = is up to the vendor that desires something to publicly state so and not for= someone else to make statements on their behalf? I mean - let's be clear - I have written a partial SRv6 / SRv6-NP implement= ation into our DPDK lab testing stack - I did it to verify certain things -= the only thing it further convinced me of is that I will never run this i= n production - in a million years - and I'd be rather concerned if someone = went out there and said on the basis of the fact that I chose to test somet= hing - I suddenly supported or liked it. What that's effectively saying is= - to test something is to support it - that's not the case. It's similar = to the line that I was given that because I signed a blue sheet in Singapor= e and didn't stand up at the microphone and publically object to something = at the time - some how my signature on the blue sheet indicated my acceptan= ce and support of the issue in question. (To quote that) PC2: The comment started because in the draft we had an example that was as= signing A:1::/32 as loopback interface for a router. This is wrong (prefix = length, documentation prefix,). This was fixed in revision 2 of the WG draft, published in September 19th 2= 019. The closure of this comment was presented by me personally in IETF Sin= gapore. Please refer to the slides. In Singapore you were present (signed b= lue sheet) and did not had any comment about such closure. This is interesting - so firstly - let me state that because I was present = in a meeting and signed a blue sheet to say I was there - in no way indicat= es that I forgo the right to object after the meeting - and last I checked,= signatures on a blue sheet are there to track attendance, not to track con= sensus. So - can I make a humble request that we let people speak for themselves ab= out what they actively support and want rather than trying to speak for oth= ers to bolster our case? Because if the case is so weak that we need to ma= ke claims on behalf of others - then there is no case at all. Thanks Andrew --_000_DM6PR05MB63485BA2D98671CD5DAF1263AEA20DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Because my name and my company have been mentioned s= o many times in this thread, I feel obliged to respond. Yet, I have no inte= rest in mud-slinging. So, I will mention a few principles that guide Junipe= r employees when participating in the IETF:

 

  • IETF mailing lists are for technical discussion
    • Demonstrate factual and intellectual honesty
    • Tre= at all participants with respect
  • IETF mailing list are not for marketing
    • Never make a marketing or positioning statement on an IETF mailing li= st
    • Never infer the intention or positioning of a compe= titor on an IETF mailing list

 

I consider all of the participants in this discussio= n to be good friends and I invite them to affirm these principles.

 

And then, my friends, let us return to technical dis= cussion.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;         Ron

 

 

Juniper Business Use Only

From: Andrew Alston <Andrew.Alston@liquidt= elecom.com>
Sent: Friday, May 8, 2020 6:56 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: Ron Bonica <rbonica@juniper.net>; Darren Dukes (ddukes) &l= t;ddukes@cisco.com>; Krzysztof Szarkowicz <kszarkowicz@gmail.com>;= 6man <6man@ietf.org>
Subject: RE: Routing Header Insertion

 

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

 

Robert,

 

Actually – it proves precisely nothing until t= hey state their motivations – and we have no right to read motivation= s into it.  We can ask them why they did it – we cannot assume a= nd nor does anyone have the right to make statements about why they chose to do something outside of someone else.

 

The twisting of words that I have seen of late has r= eally disturbed me.  Another classic case in point was where it was cl= aimed by another opponent of a draft stated the need for architectural docu= ments.  In fact what had been stated was very clear that the applications USING the protocol needed architectural d= rafts and this was merely a building block (and before I write this, I veri= fied very clear that was what was originally said, with the individual stat= ing it).  My point here is – the IETF says – every person who steps us is representing themselves as = an individual.  It is not for us to ascribe motivations to others and = then go forward and make claims about other peoples motivations.  Let = us make our case on our own technical grounds.

 

I point out that within the IETF – each person= is meant to represent themselves – and statements that imply motivat= ions of others to bolster a case in my view, do nothing more than weaken th= e argument of those making them – because if the argument is strong – then let it be made on technical grounds –= ; not on the actions of others who have not made statements about their own= motivations.

 

Andrew

 

From: Robert Raszu= k <robert@raszuk.net>
Sent: Friday, 8 May 2020 13:33
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>; Darren Dukes (dduk= es) <ddukes=3D40c= isco.com@dmarc.ietf.org>; Krzysztof Szarkowicz <kszarkowicz@gmail.com>; 6man <6man@ietf.org>
Subject: Re: Routing Header Insertion

 

 

Hey Andrew,

 

I don't think the point i= s on what one vendor desires or likes. The point is that they internally co= mmitted development resources to deliver this functionality. They also= asked one of their top talented TME Krzysiek to go and demo it. It carries a message. And all Zafar and others did was = just sharing that message. 

 

It really does not matter= that much Ron himself or on behalf of his company can jump on the lists st= ating that he does not like it. Even if Juniper marketing will no= t push it - even if they develop next cartoon mocking it - they will still likely check mark support tag on the RFP= s. 

 

All that proves that S= RH insertion is a useful feature to customers. And that's all what= matters to some IETF decisions as part of that is community needs and supp= ort for extensions under standardization.

 

Best,

Robert.

 

 

On Fri, May 8, 2020 at 12= :16 PM Andrew Alston <Andrew.Alston@liquidtelecom.com> wrote:

I do find it kinda bizarre that one vendor or an individual would jump to a= conclusion and make statements about what another one desires – sure= ly it is up to the vendor that desires something to publicly state so and n= ot for someone else to make statements on their behalf?

 

I mean – let’s be clear – I have written a partial SRv6 /= SRv6-NP implementation into our DPDK lab testing stack – I did it to= verify certain things – the only thing it further convinced me  = ;of is that I will never run this in production – in a million years – and I’d be rather concerned if someone went out there and sa= id on the basis of the fact that I chose to test something – I sudden= ly supported or liked it.  What that’s effectively saying is = 211; to test something is to support it – that’s not the case.&= nbsp; It’s similar to the line that I was given that because I signed a blue sheet in= Singapore and didn’t stand up at the microphone and publically objec= t to something at the time – some how my signature on the blue sheet = indicated my acceptance and support of the issue in question. 

 

(To quote that)

 

PC2: The comment started because in the draft we had an example that was= assigning A:1::/32 as loopback interface for a router. This is wrong (pref= ix length, documentation prefix,).

This was fixed in revision 2 of the WG draft, published in September 19<= sup>th 2019. The closure of this comment was presented by me personal= ly in IETF Singapore. Please refer to the slides. In Singapore you were pre= sent (signed blue sheet) and did not had any comment about such closure.

 

 

This is interesting – so firstly – let me state that because= I was present in a meeting and signed a blue sheet to say I was there R= 11; in no way indicates that I forgo the right to object after the meeting = – and last I checked, signatures on a blue sheet are there to track attendance, not to track consensus.

 

 

So – can I make a humble request that we let people speak for themsel= ves about what they actively support and want rather than trying to speak f= or others to bolster our case?  Because if the case is so weak that we= need to make claims on behalf of others – then there is no case at all.

 

Thanks

 

Andrew

--_000_DM6PR05MB63485BA2D98671CD5DAF1263AEA20DM6PR05MB6348namp_-- From nobody Fri May 8 07:13:46 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140C23A0AF6 for ; Fri, 8 May 2020 07:13:44 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfllVMFnGTIW for ; Fri, 8 May 2020 07:13:42 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 4462B3A074B for <6man@ietf.org>; Fri, 8 May 2020 07:13:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49JXPL0PZPz1nt2G; Fri, 8 May 2020 07:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1588947222; bh=uDuPYhP/0abu1c2HS6Z8tKuvmeG+p+3VbZk2Wnznfuo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EUdde+T48LTzqKvYTm/vz6OBNg2BsYsGyAMHfLJuHavjuqQonGov2JkIkhGTPwZrj j+VCkTelNIygTWwGmoUnkH2gmane7FunhCxSuIaesEfLSLXW0Y3cY7Hv6mSAl5dT0K GWDGuFDTMAQfkRlRdnjW8MC05g4Hk7Yv2MU/oQ0w= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 49JXPK2p9Jz1nsqK; Fri, 8 May 2020 07:13:41 -0700 (PDT) Subject: Re: Routing Header Insertion To: Robert Raszuk Cc: 6man <6man@ietf.org>, "Darren Dukes (ddukes)" References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 8 May 2020 10:13:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 14:13:44 -0000 No Robert, a vendor sending something to an interoperability test does not prove that the feature is useful to anyone. There are many possible interpretations / reasons / motivations. And for Darren, from Cisco, to assert an interpretation for Juniper and its customers seems wrong to me. If he did that to Ericsson, I would have reacted much more sharply than Ron did. Yours, Joel On 5/8/2020 6:33 AM, Robert Raszuk wrote: > > Hey Andrew, > > I don't think the point is on what one vendor desires or likes. The > point is that they internally committed development resources to deliver > this functionality. They also asked one of their top talented > TME Krzysiek to go and demo it. It carries a message. And all Zafar and > others did was just sharing that message. > > It really does not matter that much Ron himself or on behalf of his > company can jump on the lists stating that he does not like it. Even if > Juniper marketing will not push it - even if they develop next cartoon > mocking it - they will still likely check mark support tag on the RFPs. > > *All that proves that SRH insertion is a useful feature to customers.* > And that's all what matters to some IETF decisions as part of that is > community needs and support for extensions under standardization. > > Best, > Robert. > > > On Fri, May 8, 2020 at 12:16 PM Andrew Alston > > wrote: > > I do find it kinda bizarre that one vendor or an individual would > jump to a conclusion and make statements about what another one > desires – surely it is up to the vendor that desires something to > publicly state so and not for someone else to make statements on > their behalf?____ > > __ __ > > I mean – let’s be clear – I have written a partial SRv6 / SRv6-NP > implementation into our DPDK lab testing stack – I did it to verify > certain things – the only thing it further convinced me  of is that > I will never run this in production – in a million years – and I’d > be rather concerned if someone went out there and said on the basis > of the fact that I chose to test something – I suddenly supported or > liked it.  What that’s effectively saying is – to test something is > to support it – that’s not the case.  It’s similar to the line that > I was given that because I signed a blue sheet in Singapore and > didn’t stand up at the microphone and publically object to something > at the time – some how my signature on the blue sheet indicated my > acceptance and support of the issue in question. ____ > > __ __ > > (To quote that)____ > > __ __ > > /PC2: The comment started because in the draft we had an example > that was assigning A:1::/32 as loopback interface for a router. This > is wrong (prefix length, documentation prefix,).//____/ > > /This was fixed in revision 2 of the WG draft, published in > September 19^th 2019. The closure of this comment was presented by > me personally in IETF Singapore. Please refer to the slides. In > Singapore you were present (signed blue sheet) and did not had any > comment about such closure.//____/ > > ///____/ > > ///____/ > > /This is interesting – so firstly – let me state that because I was > present in a meeting and signed a blue sheet to say I was there – in > no way indicates that I forgo the right to object after the meeting > – and last I checked, signatures on a blue sheet are there to track > attendance, not to track consensus.____/ > > /__ __/ > > __ __ > > So – can I make a humble request that we let people speak for > themselves about what they actively support and want rather than > trying to speak for others to bolster our case?  Because if the case > is so weak that we need to make claims on behalf of others – then > there is no case at all.____ > > __ __ > > Thanks____ > > __ __ > > Andrew > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri May 8 08:35:36 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DBE3A0BDD for ; Fri, 8 May 2020 08:35:23 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 56J0Halx7BRg for ; Fri, 8 May 2020 08:35:20 -0700 (PDT) Received: from ESA1-Wyn.bell.ca (esa1-wyn.bell.ca [67.69.243.161]) (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 67FCE3A0BF7 for <6man@ietf.org>; Fri, 8 May 2020 08:35:19 -0700 (PDT) Received: from dm5cch-d00.bellca.int.bell.ca (HELO DG1MBX01-WYN.bell.corp.bce.ca) ([198.235.102.30]) by esa01corp-wyn.bell.corp.bce.ca with ESMTP; 08 May 2020 11:35:10 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX01-WYN.bell.corp.bce.ca (2002:8eb6:120b::8eb6:120b) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 May 2020 11:35:10 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca ([fe80::4dcc:588c:b497:9730]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::4dcc:588c:b497:9730%22]) with mapi id 15.00.1497.006; Fri, 8 May 2020 11:35:10 -0400 From: "Voyer, Daniel" To: Ron Bonica , Robert Raszuk CC: 6man <6man@ietf.org> Subject: Re: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AQHWJJd4av9EC0U0WkSKKX23xm52eqieU1OA Date: Fri, 8 May 2020 15:35:10 +0000 Message-ID: <208AE1DB-6E54-494A-8E92-8D9D41560CFF@bell.ca> 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.36.20041300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.25.6] Content-Type: multipart/alternative; boundary="_000_208AE1DB6E54494A8E928D9D41560CFFbellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 15:35:30 -0000 --_000_208AE1DB6E54494A8E928D9D41560CFFbellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9uLA0KDQo+IFRob3NlIG5lZWQgdG8gYmUgcHV0IGF0IHRoZSBlbmQgb2YgdGhlIGxpbmUs IHNvIHRoYXQgdGhleSBhcmUgdmlzaXRlZCAqYWZ0ZXIqIHRoZSBub2RlcyBpbiB0aGUgcmVwYWly IHBhdGguDQoNCkV4YWN0bHkgYXMgZGVmaW5lZCBpbiB0aGUgcHNldWRvY29kZS4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZpbHNmaWxzLXNwcmluZy1zcnY2LW5ldC1wZ20taW5z ZXJ0aW9uLTAwI3NlY3Rpb24tMy4yDQoNCkp1c3QgdG8gYWxzbyByZW1pbmQgeW91IHRoZSBjb250 ZXh0IG9mIHRoaXMgZW1haWwgaXMgU1JIIGluc2VydGlvbiBmb3IgVEktTEZBIGFzIGRlbW9uc3Ry YXRlZCBieSBKdW5pcGVyIGFuZCBvdGhlciB2ZW5kb3JzIGluIHRoZSBFQU5UQSByZXBvcnQuIE5v dGhpbmcgdG8gZG8gd2l0aCB1U0lEIHNvbHV0aW9uLg0KDQpJdOKAmXMgYWxzbyBuaWNlIHRvIGtu b3csIGZyb20gdGhlIHJlcG9ydCAtIG9idmlvdXNseSwgdGhhdCBpdCBpbnRlcm9wIHdpdGggdGhl IG90aGVyIHZlbmRvcuKAmXMgcGxhdGZvcm0uDQoNClRoYW5rcw0KZGFuDQoNCkZyb206IGlwdjYg PGlwdjYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFJvbiBCb25pY2EgPHJib25pY2E9 NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IFRodXJzZGF5LCBNYXkgNywgMjAy MCBhdCAxOjQ2IFBNDQpUbzogUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+DQpDYzog Nm1hbiA8Nm1hbkBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBSb3V0aW5nIEhlYWRlciBJbnNlcnRp b24NCg0KUm9iZXJ0LA0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBJUHY2IGRlc3RpbmF0aW9u IGFkZHJlc3MgY29udGFpbnMgNSB1U0lEIHRoYXQgcmVwcmVzZW50IDUgbm9kZXMgeWV0IHRvIGJl IHZpc2l0ZWQuIFRob3NlIG5lZWQgdG8gYmUgcHV0IGF0IHRoZSBlbmQgb2YgdGhlIGxpbmUsIHNv IHRoYXQgdGhleSBhcmUgdmlzaXRlZCAqYWZ0ZXIqIHRoZSBub2RlcyBpbiB0aGUgcmVwYWlyIHBh dGguDQoNCg0KDQpZZXMsIHRoZXJlIGFyZSBzb21lIHZlcnkgY2xldmVyIHNvbHV0aW9ucyB0aGF0 IHlvdSBhbmQgSSB1bmRlcnN0YW5kLiBCdXQgd2lsbCB0aGUgZ3V5IGluIHRoZSBOT0Mgd2hvIGRv ZXNu4oCZdCBsaXZlIGFuZCBicmVhdGggU1IgYmUgYWJsZSB0byBmaWd1cmUgaXQgb3V0IHRoZSBm aXJzdCB0aW1lIGhlIHNlZXMgaXQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KDQoN Ckp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCkZyb206IFJvYmVydCBSYXN6dWsgPHJvYmVydEBy YXN6dWsubmV0Pg0KU2VudDogVGh1cnNkYXksIE1heSA3LCAyMDIwIDE6MjggUE0NClRvOiBSb24g Qm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0Pg0KQ2M6IFZveWVyLCBEYW5pZWwgPGRhbmllbC52 b3llckBiZWxsLmNhPjsgRXJpYyBWeW5ja2UgKGV2eW5ja2UpIDxldnluY2tlQGNpc2NvLmNvbT47 IDZtYW4gPDZtYW5AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUm91dGluZyBIZWFkZXIgSW5zZXJ0 aW9uDQoNCltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCg0KSGkgUm9u LA0KDQo+ICBZZXMsIHRoZSBwcm9ibGVtIGNhbiBiZSBzb2x2ZWQsIGJ1dCBub3Qgd2l0aG91dCBk ZWVwIHRob3VnaCBhbmQgdmlnb3JvdXMgaGVhZCBzY3JhdGNoaW5nLg0KDQpXZWxsIGRvbid0IHdl IHN0aWxsIGhhdmUgdGhlIGluZGljYXRvcnMgb2YgQWN0aXZlLCBOZXh0IGFuZCBMYXN0IHVTSURz IGluIFNSSCA/IElmIHNvIHdoYXQgaXMgc28gZGlmZmljdWx0IGlmIHlvdSBrZWVwIHlvdXIgb3Jp Z2luYWwgU1JIIGFzIGlzIGFuZCBwcm92aWRlIEZSUiB1c2luZyBuZXcgU1JIID8gTW9yZW92ZXIg aWYgeW91IFBPUCB0aGUgYWRkaXRpb25hbCBTUkggQCBwdG90ZWN0aWVkIHBhdGggUEhQIEZSUiBl bmRwb2ludCBtYXkgbm90IGV2ZW4gbm90aWNlZCBoZSBpcyBhY3RpbmcgYXMgc3VjaCBlbmRwb2lu dCBhbmQgdGhhdCBpcyB2ZXJ5IGNvb2wgdGhpbmcuDQoNClRoZSBwcm9ibGVtIHBlcmhhcHMgYmVj b21lcyBhIG5pY2UgZXhlcmNpc2UgdG8gc29sdmUgaG93IHRvIGhhbmRsZSBUSS1MRkEgd2hlbiB5 b3UgaGF2ZSB1U0lEIGxpc3QgaW4gREEgYWRkcmVzcyBvZiB0aGUgcGFja2V0cyBhbmQgd2hlcmUg dGhlcmUgaXMgbm8gU1JIIGF0IGFsbCA6KSBDbGVhcmx5IGEgdmFsaWQgZGVwbG95bWVudCBzY2Vu YXJpby4gQnV0IHNpbmNlIHlvdSBhcmUgYWxyZWFkeSBkZWVwIGludG8gaXQgSSB3aWxsIGxldCB5 b3UgZmlndXJlIGl0IG91dCA6KQ0KDQo+IFdoZW4gYSBzb2x1dGlvbiBpcyB0aGF0IGNvbXBsZXgs IGl0IGlzIHByb2JhYmx5IGJleW9uZCB0aGUgY2FwYWJpbGl0eSBvZiBhbnkgb3BlcmF0aW9ucyBz dGFmZi4NCg0KV2VsbCBpdCB3b3VsZCBiZSBhIG1pc3Rha2UgdG8gY291bnQgb24gYWxsIG9wZXJh dG9ycyBkb2luZyB0aGlzIGhhbmRsaW5nIGluIFA0IGNvZGUgb24gdGhlaXIgb3duIGN1c3RvbSBw bGF0Zm9ybXMuIEZvciByZXN0IG9mIHRoZW0gYSBzaW1wbGUga25vYiB3b3VsZCBiZSBzdWZmaWNp ZW50IHRvIGVuYWJsZSBpdCBhbmQgZW5qb3kuDQoNClRoeCwNClIuDQoNCg0KT24gVGh1LCBNYXkg NywgMjAyMCBhdCA3OjAzIFBNIFJvbiBCb25pY2EgPHJib25pY2E9NDBqdW5pcGVyLm5ldEBkbWFy Yy5pZXRmLm9yZzxtYWlsdG86NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0K SGkgRGFuaWVsLA0KDQpUSS1MRkEgd2l0aCBTUkggaW5zZXJ0aW9uIHBvc2VzIHByb2JsZW1zIGlu IHRoZSBmb2xsb3dpbmcgY2FzZXM6DQoNCg0KICAqICAgV2hlbiB0aGUgcGFja2V0IGFscmVhZHkg Y29udGFpbnMgYW4gU1JIDQogICogICBXaGVuIHRoZSBJUHY2IERlc3RpbmF0aW9uIEFkZHJlc3Mg Y29udGFpbnMgdVNJRHMNCg0KSW4gdGhlIGZpcnN0IGNhc2UsIHdoZW4gdGhlIHBhY2tldCBhbHJl YWR5IGNvbnRhaW5zIGFuIFNSSCwgVEktTEZBIHdpdGggU1JIIGluc2VydGlvbiByZXN1bHRzIGlu IGEgc2luZ2xlIHBhY2tldCB0aGF0IGNvbnRhaW5zIHR3byBTUkjigJlzLiBObyByZWFkaW5nIG9m IFJGQyA4MjAwIGFsbG93cyB0aGlzLg0KDQpUaGUgc2Vjb25kIGNhc2UgaXMgbW9yZSBjb21wbGV4 LiBBc3N1bWUgdGhhdCBpbiB5b3VyIHVTSUQgc3RyYXRlZ3k6DQoNCg0KICAqICAgVGhlIHVTSUQg YmxvY2sgaWRlbnRpZmllciBpcyAzMiBiaXRzIGxvbmcNCiAgKiAgIEVhY2ggdVNJRCBpcyAxNiBi aXRzIGxvbmcNCiAgKiAgIFRoZSBlbmQtb2YtY2FycmllciBtYXJrZXIgaXMgYWxzbyAxNiBiaXRz IGxvbmcNCg0KSW4gdGhpcyBjYXNlLCB5b3UgY2FuIGZpdCA1IHVTSURzIGluIHRoZSBJUHY2IGFk ZHJlc3MuDQoNCk9uIHRoZSBmaXJzdCBzZWdtZW50LCB3aGVuIHRoZSBkZXN0aW5hdGlvbiBhZGRy ZXNzIHN0aWxsIGNvbnRhaW5zIDUgdVNJRHMsIGEgUExSIGRldGVjdHMgbGluayBmYWlsdXJlIGFu ZCBpbnZva2VzIFRJLUxGQSBwcm9jZWR1cmVzLiBUaGUgcmVwYWlyIHR1bm5lbCBjb250YWlucyAz IHNlZ21lbnRzLiBJZiB0aGUgUExSIGV4ZWN1dGVzIFRJLUxGQSB3aXRoIGluc2VydGlvbiBwcm9j ZWR1cmVzLCB3aGF0IGRvZXMgdGhlIHJlc3VsdGluZyBJUHY2IERlc3RpbmF0aW9uIGFkZHJlc3Mg bG9vayBsaWtlPyBXaGF0IGRvZXMgdGhlIFNSSCBsb29rIGxpa2U/DQoNClllcywgdGhlIHByb2Js ZW0gY2FuIGJlIHNvbHZlZCwgYnV0IG5vdCB3aXRob3V0IGRlZXAgdGhvdWdoIGFuZCB2aWdvcm91 cyBoZWFkIHNjcmF0Y2hpbmcuIFdoZW4gYSBzb2x1dGlvbiBpcyB0aGF0IGNvbXBsZXgsIGl0IGlz IHByb2JhYmx5IGJleW9uZCB0aGUgY2FwYWJpbGl0eSBvZiBhbnkgb3BlcmF0aW9ucyBzdGFmZi4N Cg0KVGhlIGFib3ZlLW1lbnRpb25lZCBwcm9ibGVtcyBjb3VsZCBoYXZlIGJlZW4gYXZvaWRlZCBp ZiBUSS1MRkEgY3JlYXRlZCBpdHMgcmVwYWlyIHR1bm5lbCBieSBwcmVwZW5kaW5nIGFuIElQdjYg aGVhZGVyIHdpdGggaXRzIG93biBTUkguDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBSb24NCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo= --_000_208AE1DB6E54494A8E928D9D41560CFFbellca_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TGF0bzsNCglw YW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zaXBmb290ZXIzMGIzZDUzOCwgbGkubXNpcGZvb3RlcjMwYjNkNTM4LCBkaXYu bXNpcGZvb3RlcjMwYjNkNTM4DQoJe21zby1zdHlsZS1uYW1lOm1zaXBmb290ZXIzMGIzZDUzODsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY4NjE4NjI0 Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMjg4NzA5NjYwO30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDozNDQ4NzA4Njc7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjg4ODcwNTkxNDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6NjQwMzUyOTkwOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczoxMjQ5OTQyMjk0O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxNzc1MDUyNDQ2Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxNDQzMjcyOTY2O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUm9uLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwO1Rob3NlIG5lZWQgdG8gYmUgcHV0IGF0IHRoZSBlbmQg b2YgdGhlIGxpbmUsIHNvIHRoYXQgdGhleSBhcmUgdmlzaXRlZCAqPGI+YWZ0ZXI8L2I+KiB0aGUg bm9kZXMgaW4gdGhlIHJlcGFpciBwYXRoLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPkV4 YWN0bHkgYXMgZGVmaW5lZCBpbiB0aGUgcHNldWRvY29kZS4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1maWxzZmlscy1zcHJpbmctc3J2Ni1uZXQtcGdtLWluc2VydGlv bi0wMCNzZWN0aW9uLTMuMiIgdGl0bGU9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1maWxzZmlscy1zcHJpbmctc3J2Ni1uZXQtcGdtLWluc2VydGlvbi0wMCNzZWN0aW9uLTMuMiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkm cXVvdDs7Y29sb3I6IzA1NjNDMTtiYWNrZ3JvdW5kOndoaXRlIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNydjYtbmV0LXBnbS1pbnNlcnRpb24tMDAj c2VjdGlvbi0zLjI8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkp1c3QgdG8g YWxzbyByZW1pbmQgeW91Jm5ic3A7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPnRoZSBj b250ZXh0IG9mIHRoaXMgZW1haWwgaXMgU1JIIGluc2VydGlvbiBmb3IgVEktTEZBIGFzIGRlbW9u c3RyYXRlZCBieSBKdW5pcGVyIGFuZCBvdGhlciB2ZW5kb3JzIGluIHRoZSBFQU5UQSByZXBvcnQu IE5vdGhpbmcgdG8gZG8gd2l0aCB1U0lEIHNvbHV0aW9uLjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXTigJlzIGFsc28gbmljZSB0byBrbm93LCBmcm9tIHRoZSByZXBvcnQgLSBvYnZp b3VzbHksIHRoYXQgaXQgaW50ZXJvcCB3aXRoIHRoZSBvdGhlciB2ZW5kb3LigJlzIHBsYXRmb3Jt LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmRhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+aXB2NiAmbHQ7aXB2Ni1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgUm9uIEJv bmljYSAmbHQ7cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxi PkRhdGU6IDwvYj5UaHVyc2RheSwgTWF5IDcsIDIwMjAgYXQgMTo0NiBQTTxicj4NCjxiPlRvOiA8 L2I+Um9iZXJ0IFJhc3p1ayAmbHQ7cm9iZXJ0QHJhc3p1ay5uZXQmZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj42bWFuICZsdDs2bWFuQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogUm91 dGluZyBIZWFkZXIgSW5zZXJ0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJvYmVydCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHBy b2JsZW0gaXMgdGhhdCB0aGUgSVB2NiBkZXN0aW5hdGlvbiBhZGRyZXNzIGNvbnRhaW5zIDUgdVNJ RCB0aGF0IHJlcHJlc2VudCA1IG5vZGVzIHlldCB0byBiZSB2aXNpdGVkLiBUaG9zZSBuZWVkIHRv IGJlIHB1dCBhdCB0aGUgZW5kIG9mIHRoZSBsaW5lLCBzbyB0aGF0IHRoZXkgYXJlIHZpc2l0ZWQg KjxiPmFmdGVyPC9iPiogdGhlIG5vZGVzIGluIHRoZSByZXBhaXIgcGF0aC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhlcmUgYXJl IHNvbWUgdmVyeSBjbGV2ZXIgc29sdXRpb25zIHRoYXQgeW91IGFuZCBJIHVuZGVyc3RhbmQuIEJ1 dCB3aWxsIHRoZSBndXkgaW4gdGhlIE5PQyB3aG8gZG9lc27igJl0IGxpdmUgYW5kIGJyZWF0aCBT UiBiZSBhYmxlIHRvIGZpZ3VyZSBpdCBvdXQgdGhlIGZpcnN0IHRpbWUgaGUgc2VlcyBpdC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im1zaXBmb290ZXIzMGIzZDUzOCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1h cmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2siPkp1bmlwZXIgQnVzaW5lc3MgVXNl IE9ubHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFJvYmVydCBSYXN6dWsgJmx0 O3JvYmVydEByYXN6dWsubmV0Jmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSA3 LCAyMDIwIDE6MjggUE08YnI+DQo8Yj5Ubzo8L2I+IFJvbiBCb25pY2EgJmx0O3Jib25pY2FAanVu aXBlci5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBWb3llciwgRGFuaWVsICZsdDtkYW5pZWwudm95 ZXJAYmVsbC5jYSZndDs7IEVyaWMgVnluY2tlIChldnluY2tlKSAmbHQ7ZXZ5bmNrZUBjaXNjby5j b20mZ3Q7OyA2bWFuICZsdDs2bWFuQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogUm91dGluZyBIZWFkZXIgSW5zZXJ0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuMHB0O2JhY2tncm91bmQ6I0ZGRUI5QyI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6TGF0bztjb2xvcjpi bGFjayI+W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XTwvc3Bhbj48L2I+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJvbiw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZu YnNwOyBZZXMsIHRoZSBwcm9ibGVtIGNhbiBiZSBzb2x2ZWQsIGJ1dCBub3Qgd2l0aG91dCBkZWVw IHRob3VnaCBhbmQgdmlnb3JvdXMgaGVhZCBzY3JhdGNoaW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZWxsIGRvbid0IHdlIHN0 aWxsIGhhdmUgdGhlIGluZGljYXRvcnMgb2YgQWN0aXZlLCBOZXh0IGFuZCBMYXN0IHVTSURzIGlu IFNSSCA/IElmIHNvIHdoYXQgaXMgc28gZGlmZmljdWx0IGlmIHlvdSBrZWVwIHlvdXIgb3JpZ2lu YWwgU1JIIGFzIGlzIGFuZCBwcm92aWRlIEZSUiB1c2luZyBuZXcgU1JIID8gTW9yZW92ZXIgaWYg eW91IFBPUCB0aGUgYWRkaXRpb25hbCBTUkggQCBwdG90ZWN0aWVkIHBhdGggUEhQDQogRlJSIGVu ZHBvaW50IG1heSBub3QgZXZlbiBub3RpY2VkIGhlIGlzIGFjdGluZyBhcyBzdWNoIGVuZHBvaW50 IGFuZCB0aGF0IGlzIHZlcnkgY29vbCB0aGluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb2JsZW0gcGVyaGFwcyBiZWNv bWVzIGEgbmljZSBleGVyY2lzZSZuYnNwO3RvIHNvbHZlIGhvdyB0byBoYW5kbGUgVEktTEZBIHdo ZW4geW91IGhhdmUgdVNJRCBsaXN0IGluIERBIGFkZHJlc3Mgb2YgdGhlIHBhY2tldHMgYW5kIHdo ZXJlIHRoZXJlIGlzIG5vIFNSSCBhdCBhbGwgOikgQ2xlYXJseSBhIHZhbGlkJm5ic3A7ZGVwbG95 bWVudCBzY2VuYXJpby4gQnV0IHNpbmNlIHlvdSBhcmUgYWxyZWFkeSBkZWVwIGludG8NCiBpdCBJ IHdpbGwgbGV0IHlvdSBmaWd1cmUgaXQgb3V0IDopJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgV2hlbiBhIHNvbHV0aW9uIGlz IHRoYXQgY29tcGxleCwgaXQgaXMgcHJvYmFibHkgYmV5b25kIHRoZSBjYXBhYmlsaXR5IG9mIGFu eSBvcGVyYXRpb25zIHN0YWZmLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZWxsIGl0IHdvdWxkIGJlIGEgbWlzdGFrZSB0 byBjb3VudCBvbiBhbGwgb3BlcmF0b3JzIGRvaW5nIHRoaXMgaGFuZGxpbmcgaW4gUDQgY29kZSBv biB0aGVpciBvd24gY3VzdG9tIHBsYXRmb3Jtcy4gRm9yIHJlc3Qgb2YgdGhlbSBhIHNpbXBsZSBr bm9iIHdvdWxkIGJlIHN1ZmZpY2llbnQmbmJzcDt0byBlbmFibGUgaXQgYW5kIGVuam95LiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aHgsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUs IE1heSA3LCAyMDIwIGF0IDc6MDMgUE0gUm9uIEJvbmljYSAmbHQ7cmJvbmljYT08YSBocmVmPSJt YWlsdG86NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyI+NDBqdW5pcGVyLm5ldEBkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5IaSBEYW5pZWwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5USS1MRkEgd2l0aCBTUkggaW5zZXJ0aW9uIHBvc2VzIHByb2JsZW1zIGluIHRoZSBmb2xsb3dp bmcgY2FzZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+DQpXaGVuIHRoZSBwYWNrZXQgYWxyZWFkeSBjb250YWlu cyBhbiBTUkg8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps MyBsZXZlbDEgbGZvMyI+DQpXaGVuIHRoZSBJUHY2IERlc3RpbmF0aW9uIEFkZHJlc3MgY29udGFp bnMgdVNJRHM8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIHRoZSBmaXJzdCBj YXNlLCB3aGVuIHRoZSBwYWNrZXQgYWxyZWFkeSBjb250YWlucyBhbiBTUkgsIFRJLUxGQSB3aXRo IFNSSCBpbnNlcnRpb24gcmVzdWx0cyBpbiBhIHNpbmdsZSBwYWNrZXQgdGhhdCBjb250YWlucyB0 d28gU1JI4oCZcy4gTm8gcmVhZGluZyBvZiBSRkMgODIwMCBhbGxvd3MgdGhpcy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlRoZSBzZWNvbmQgY2FzZSBpcyBtb3JlIGNvbXBsZXguIEFzc3Vt ZSB0aGF0IGluIHlvdXIgdVNJRCBzdHJhdGVneTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm82Ij4NClRoZSB1U0lEIGJs b2NrIGlkZW50aWZpZXIgaXMgMzIgYml0cyBsb25nPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzYiPg0KRWFjaCB1U0lEIGlzIDE2IGJp dHMgbG9uZzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omwx IGxldmVsMSBsZm82Ij4NClRoZSBlbmQtb2YtY2FycmllciBtYXJrZXIgaXMgYWxzbyAxNiBiaXRz IGxvbmc8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIHRoaXMgY2FzZSwgeW91 IGNhbiBmaXQgNSB1U0lEcyBpbiB0aGUgSVB2NiBhZGRyZXNzLg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5PbiB0aGUgZmlyc3Qgc2VnbWVudCwgd2hlbiB0aGUgZGVzdGluYXRpb24gYWRk cmVzcyBzdGlsbCBjb250YWlucyA1IHVTSURzLCBhIFBMUiBkZXRlY3RzIGxpbmsgZmFpbHVyZSBh bmQgaW52b2tlcyBUSS1MRkEgcHJvY2VkdXJlcy4gVGhlIHJlcGFpciB0dW5uZWwgY29udGFpbnMg MyBzZWdtZW50cy4gSWYgdGhlDQogUExSIGV4ZWN1dGVzIFRJLUxGQSB3aXRoIGluc2VydGlvbiBw cm9jZWR1cmVzLCB3aGF0IGRvZXMgdGhlIHJlc3VsdGluZyBJUHY2IERlc3RpbmF0aW9uIGFkZHJl c3MgbG9vayBsaWtlPyBXaGF0IGRvZXMgdGhlIFNSSCBsb29rIGxpa2U/PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5ZZXMsIHRoZSBwcm9ibGVtIGNhbiBiZSBzb2x2ZWQsIGJ1dCBub3Qgd2l0 aG91dCBkZWVwIHRob3VnaCBhbmQgdmlnb3JvdXMgaGVhZCBzY3JhdGNoaW5nLiBXaGVuIGEgc29s dXRpb24gaXMgdGhhdCBjb21wbGV4LCBpdCBpcyBwcm9iYWJseSBiZXlvbmQgdGhlIGNhcGFiaWxp dHkgb2YgYW55IG9wZXJhdGlvbnMNCiBzdGFmZi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRoZSBhYm92ZS1tZW50aW9uZWQgcHJvYmxlbXMgY291bGQgaGF2ZSBiZWVuIGF2b2lkZWQgaWYg VEktTEZBIGNyZWF0ZWQgaXRzIHJlcGFpciB0dW5uZWwgYnkgcHJlcGVuZGluZyBhbiBJUHY2IGhl YWRlciB3aXRoIGl0cyBvd24gU1JILjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O1JvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbjo1LjBwdDt0ZXh0LWFsaWduOmNl bnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+SnVuaXBlciBC dXNpbmVzcyBVc2UgT25seTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_208AE1DB6E54494A8E928D9D41560CFFbellca_-- From nobody Fri May 8 08:36:22 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1893A0C76 for ; Fri, 8 May 2020 08:36:08 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 N3WmAMt4H-po for ; Fri, 8 May 2020 08:35:55 -0700 (PDT) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4F23A0BE4 for <6man@ietf.org>; Fri, 8 May 2020 08:35:49 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2051.outbound.protection.outlook.com [104.47.13.51]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-39-d8SU-fHDMR-45X3BijtNTg-1; Fri, 08 May 2020 16:35:44 +0100 X-MC-Unique: d8SU-fHDMR-45X3BijtNTg-1 Received: from AM6PR03MB5047.eurprd03.prod.outlook.com (2603:10a6:20b:89::13) by AM6PR03MB3669.eurprd03.prod.outlook.com (2603:10a6:209:3c::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26; Fri, 8 May 2020 15:35:42 +0000 Received: from AM6PR03MB5047.eurprd03.prod.outlook.com ([fe80::8081:95b4:8a9d:e05d]) by AM6PR03MB5047.eurprd03.prod.outlook.com ([fe80::8081:95b4:8a9d:e05d%6]) with mapi id 15.20.2979.030; Fri, 8 May 2020 15:35:42 +0000 From: Andrew Alston To: Ron Bonica , Robert Raszuk CC: "Darren Dukes (ddukes)" , Krzysztof Szarkowicz , 6man <6man@ietf.org> Subject: RE: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AQHWI58t0MrEgFbBRG+Eev5I1WHYlaia/q4AgAHXnICAAAry0IABGRowgAAGnQCAAAB1UIAAK7KQgAAmwYA= Date: Fri, 8 May 2020 15:35:42 +0000 Message-ID: References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> 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_SetDate=2020-05-08T13:27:39Z; 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=d6f30132-893a-4829-a0bf-5bcb370694dd; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 x-originating-ip: [2c0f:fe40:3:2:8127:1b33:8af4:f0ec] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3d48adf2-ccfd-4c8e-e2b4-08d7f36577f3 x-ms-traffictypediagnostic: AM6PR03MB3669: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 039735BC4E x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: A5Kec8lZA7yWTskMcTKEi4mrOM90jO2oeUlpmVHGPHspzgC6cj8Sh1XSnNkgTmD9KC8vGQzwDZcSil1RtHw5ZLc8ijx+D9TyNhEtkyA1plrzPzVe36fxksFoYqlVSawYWrVdrvpZKVs8FuC3fVoTSsIVrjIZPIp/VUcGZKKPVK43YiC9RKrIqxlgkWI5fYxLr7OiiYZsGi4CSjsvdeMUxHDWaRQWhrmiC+UynSl9/6kiYNyDpzL02roJq/vlO8F7ITyzPxPWbQzrP7tSD2JqDDwgC2M3UPyiahk/VXJSTwM1DKlDsJhPiswn7BjJvv1OaDxhOSGx4b7D2q7HSuySUqqjCdpKUL/t+hLmdrcNusFdzoWTytDmAPHUhr1AKQiF3gB7OfVoeHIs1K9Re9ekOMFKGJlwmTBfxSGE7lEx2HGYKxMaK8wIYwZgOri20ZfxqjKZmMdEmOJDpAmxUXubMP3uj2f0FKAwKQ7EHUimVDc/ir6MhKlPgc1rAVwUPLo1S1Plyvy8GVoQRdJpEGdwng== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR03MB5047.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(136003)(376002)(396003)(366004)(33430700001)(8936002)(478600001)(33656002)(316002)(71200400001)(110136005)(54906003)(52536014)(7696005)(83300400001)(6506007)(83280400001)(83320400001)(83290400001)(83310400001)(3480700007)(76116006)(66574014)(186003)(66446008)(53546011)(86362001)(7116003)(5660300002)(33440700001)(55016002)(66476007)(2906002)(8676002)(66946007)(4326008)(9686003)(66556008)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: OFrRARUSbpjYDF/tmv3j5n2q9nOKy1J/NlkrHRoNOw3qlMqx6UI92WJJepqgxLc1dqyaL/XDDgiZilRXRFGNORCvuJ4/bAsNyr4B+WVVS9odOnkOEETEW4rCt3Z/38Ljvz3mrZZc3+Gfg9NXPeNhsDfBfCM10xrX0M+tuWvJ3W1yxBriO7zzkojfs8JXoJ2uGxZxINqoZOKmUuiTQZ9XZF15DRX7vSKXO4P9VCsg+dr+8y58xwmsCuga77hoU4sE/vIyqRq0PaMGN2jVdyKvMvEWNVr91zRsoWLHKS7NRf7ewO92RPkBvlCCtq2ODP4+noaSpW5wriEFn6xAhtKy6PW4e72TTSdP+AtfTa6GPfq/EbXJoqirITO+AQd3UZbhtv7O+AXHZAXcVUn3neHWq5TH630zIW/XITyxp5wmJ3s/N1BpVNC24/dQpEkYbMELjF5iWX9Q3UYS+Gv6LLFPpcwr6d9a19y+L4Ms+4HYEfNWXF/L4V5iWxPiaN9Sb63ppDi86OIz3lvb/+GipnEKlhI7DZDnZGx3QZrAy5ulwrw= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3d48adf2-ccfd-4c8e-e2b4-08d7f36577f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 15:35:42.4823 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5EKiU0TJXe634cMkaw6REyC2ihi7r+edpA5GIXHLFNmJ3LdjCremRV6PfoaljTlwG8IJO/xHf7FV+46DkL7Fj0Rt5Sgwyb9BT1xqwfDGkK0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR03MB3669 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Type: multipart/alternative; boundary="_000_AM6PR03MB50473D24C7ABA4E6CFC9603DEEA20AM6PR03MB5047eurp_" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 15:36:15 -0000 --_000_AM6PR03MB50473D24C7ABA4E6CFC9603DEEA20AM6PR03MB5047eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Ron, Thanks for your very magnanimous reply, and I think that the principles out= lined below by yourself are solid. I think if we can get back to discussin= g drafts purely on their technical merits - rather than the statements abou= t what others want - it would certainly serve both the working group and th= e community at large better than the current situation. Thanks Andrew From: Ron Bonica Sent: Friday, 8 May 2020 16:28 To: Andrew Alston ; Robert Raszuk Cc: Darren Dukes (ddukes) ; Krzysztof Szarkowicz ; 6man <6man@ietf.org> Subject: RE: Routing Header Insertion Folks, Because my name and my company have been mentioned so many times in this th= read, I feel obliged to respond. Yet, I have no interest in mud-slinging. S= o, I will mention a few principles that guide Juniper employees when partic= ipating in the IETF: - IETF mailing lists are for technical discussion o Demonstrate factual and intellectual honesty o Treat all participants with respect - IETF mailing list are not for marketing o Never make a marketing or positioning statement on an IETF mailing list o Never infer the intention or positioning of a competitor on an IETF mai= ling list I consider all of the participants in this discussion to be good friends an= d I invite them to affirm these principles. And then, my friends, let us return to technical discussion. = Ron Juniper Business Use Only From: Andrew Alston Sent: Friday, May 8, 2020 6:56 AM To: Robert Raszuk Cc: Ron Bonica ; Darren Dukes (ddukes) ; Krzysztof Szarkowicz ; 6man <6man@ietf.org> Subject: RE: Routing Header Insertion [External Email. Be cautious of content] Robert, Actually - it proves precisely nothing until they state their motivations -= and we have no right to read motivations into it. We can ask them why the= y did it - we cannot assume and nor does anyone have the right to make stat= ements about why they chose to do something outside of someone else. The twisting of words that I have seen of late has really disturbed me. An= other classic case in point was where it was claimed by another opponent of= a draft stated the need for architectural documents. In fact what had bee= n stated was very clear that the applications USING the protocol needed arc= hitectural drafts and this was merely a building block (and before I write = this, I verified very clear that was what was originally said, with the ind= ividual stating it). My point here is - the IETF says - every person who s= teps us is representing themselves as an individual. It is not for us to a= scribe motivations to others and then go forward and make claims about othe= r peoples motivations. Let us make our case on our own technical grounds. I point out that within the IETF - each person is meant to represent themse= lves - and statements that imply motivations of others to bolster a case in= my view, do nothing more than weaken the argument of those making them - b= ecause if the argument is strong - then let it be made on technical grounds= - not on the actions of others who have not made statements about their ow= n motivations. Andrew From: Robert Raszuk > Sent: Friday, 8 May 2020 13:33 To: Andrew Alston > Cc: Ron Bonica >; Darren Dukes (ddukes) >; Krzysztof Szarko= wicz >; 6man <6man@ietf= .org> Subject: Re: Routing Header Insertion Hey Andrew, I don't think the point is on what one vendor desires or likes. The point i= s that they internally committed development resources to deliver this func= tionality. They also asked one of their top talented TME Krzysiek to go and= demo it. It carries a message. And all Zafar and others did was just shari= ng that message. It really does not matter that much Ron himself or on behalf of his company= can jump on the lists stating that he does not like it. Even if Juniper ma= rketing will not push it - even if they develop next cartoon mocking it - t= hey will still likely check mark support tag on the RFPs. All that proves that SRH insertion is a useful feature to customers. And th= at's all what matters to some IETF decisions as part of that is community n= eeds and support for extensions under standardization. Best, Robert. On Fri, May 8, 2020 at 12:16 PM Andrew Alston > wrote: I do find it kinda bizarre that one vendor or an individual would jump to a= conclusion and make statements about what another one desires - surely it = is up to the vendor that desires something to publicly state so and not for= someone else to make statements on their behalf? I mean - let's be clear - I have written a partial SRv6 / SRv6-NP implement= ation into our DPDK lab testing stack - I did it to verify certain things -= the only thing it further convinced me of is that I will never run this i= n production - in a million years - and I'd be rather concerned if someone = went out there and said on the basis of the fact that I chose to test somet= hing - I suddenly supported or liked it. What that's effectively saying is= - to test something is to support it - that's not the case. It's similar = to the line that I was given that because I signed a blue sheet in Singapor= e and didn't stand up at the microphone and publically object to something = at the time - some how my signature on the blue sheet indicated my acceptan= ce and support of the issue in question. (To quote that) PC2: The comment started because in the draft we had an example that was as= signing A:1::/32 as loopback interface for a router. This is wrong (prefix = length, documentation prefix,). This was fixed in revision 2 of the WG draft, published in September 19th 2= 019. The closure of this comment was presented by me personally in IETF Sin= gapore. Please refer to the slides. In Singapore you were present (signed b= lue sheet) and did not had any comment about such closure. This is interesting - so firstly - let me state that because I was present = in a meeting and signed a blue sheet to say I was there - in no way indicat= es that I forgo the right to object after the meeting - and last I checked,= signatures on a blue sheet are there to track attendance, not to track con= sensus. So - can I make a humble request that we let people speak for themselves ab= out what they actively support and want rather than trying to speak for oth= ers to bolster our case? Because if the case is so weak that we need to ma= ke claims on behalf of others - then there is no case at all. Thanks Andrew --_000_AM6PR03MB50473D24C7ABA4E6CFC9603DEEA20AM6PR03MB5047eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi Ron,

 

Thanks for your very magnanimous reply, and I think that the principl= es outlined below by yourself are solid.  I think if we can get back t= o discussing drafts purely on their technical merits – rather than the statements about what others want – i= t would certainly serve both the working group and the community at large b= etter than the current situation.

 

Thanks

 

Andrew

 

 

From: Ron Bonica <rbonica@juniper.net&g= t;
Sent: Friday, 8 May 2020 16:28
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>; Robert Ra= szuk <robert@raszuk.net>
Cc: Darren Dukes (ddukes) <ddukes@cisco.com>; Krzysztof Szarko= wicz <kszarkowicz@gmail.com>; 6man <6man@ietf.org>
Subject: RE: Routing Header Insertion

 

Fo= lks,

 

Be= cause my name and my company have been mentioned so many times in this thre= ad, I feel obliged to respond. Yet, I have no interest in mud-slinging. So,= I will mention a few principles that guide Juniper employees when participating in the IETF:<= /p>

 

-=    &n= bsp;    IETF mailing lists are = for technical discussion

o   Demonstrate factual and= intellectual honesty

o   Treat all participants = with respect

-=    &n= bsp;    IETF mailing list are n= ot for marketing

o   Never make a marketing = or positioning statement on an IETF mailing list

o   Never infer the intenti= on or positioning of a competitor on an IETF mailing list=

 

I = consider all of the participants in this discussion to be good friends and = I invite them to affirm these principles.

 

An= d then, my friends, let us return to technical discussion.

 

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;     Ron

 

 

Juniper Business= Use Only

From: Andrew Alston <Andrew.Alston@liqu= idtelecom.com>
Sent: Friday, May 8, 2020 6:56 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: Ron Bonica <rbonica@juniper.net>; Darren Dukes (ddukes) &l= t;ddukes@cisco.com>; Krzysztof Szarkowicz <kszarkowicz@gmail.com>;= 6man <6man@ietf.org>
Subject: RE: Routing Header Insertion

 

[External Email. Be cautious of content]

 

Ro= bert,

 

Ac= tually – it proves precisely nothing until they state their motivatio= ns – and we have no right to read motivations into it.  We can a= sk them why they did it – we cannot assume and nor does anyone have the right to make statements about why they chose to do someth= ing outside of someone else.

 

Th= e twisting of words that I have seen of late has really disturbed me. = Another classic case in point was where it was claimed by another opponent= of a draft stated the need for architectural documents.  In fact what had been stated was very clear that the appl= ications USING the protocol needed architectural drafts and this was merely= a building block (and before I write this, I verified very clear that was = what was originally said, with the individual stating it).  My point here is – the IETF says – every pe= rson who steps us is representing themselves as an individual.  It is = not for us to ascribe motivations to others and then go forward and make cl= aims about other peoples motivations.  Let us make our case on our own technical grounds.

 

I = point out that within the IETF – each person is meant to represent th= emselves – and statements that imply motivations of others to bolster= a case in my view, do nothing more than weaken the argument of those making them – because if the argument is strong &#= 8211; then let it be made on technical grounds – not on the actions o= f others who have not made statements about their own motivations.

 

An= drew

 

From: Robert Raszuk <robert@raszuk.net>
Sent: Friday, 8 May 2020 13:33
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>; Darren Dukes (dduk= es) <ddukes=3D40c= isco.com@dmarc.ietf.org>; Krzysztof Szarkowicz <kszarkowicz@gmail.com>; 6man <6man@ietf.org>
Subject: Re: Routing Header Insertion

 

 

He= y Andrew,

 

I = don't think the point is on what one vendor desires or likes. The point is = that they internally committed development resources to deliver this f= unctionality. They also asked one of their top talented TME Krzysiek to go and demo it. It carries a message. An= d all Zafar and others did was just sharing that message. <= /span>

 

It= really does not matter that much Ron himself or on behalf of his company c= an jump on the lists stating that he does not like it. Even if Ju= niper marketing will not push it - even if they develop next cartoon mocking it - they will still likely check mark support tag on= the RFPs. 

 

All that proves that SRH insertion is a useful feature to customers.<= /span> And that's all what matters to some IETF de= cisions as part of that is community needs and support for extensions under standardization.

 

Be= st,

Ro= bert.

 

 

On= Fri, May 8, 2020 at 12:16 PM Andrew Alston <Andrew.Alston@liquidtelecom.com> wrote:=

I do find it kinda bizarre that one vendor or an indiv= idual would jump to a conclusion and make statements about what another one= desires – surely it is up to the vendor that desires something to pu= blicly state so and not for someone else to make statements on their behalf?

 

I mean – let’s be clear – I have wri= tten a partial SRv6 / SRv6-NP implementation into our DPDK lab testing stac= k – I did it to verify certain things – the only thing it furth= er convinced me  of is that I will never run this in production – in a million years – and I’d be rather concerned if so= meone went out there and said on the basis of the fact that I chose to test= something – I suddenly supported or liked it.  What that’= s effectively saying is – to test something is to support it – = that’s not the case.  It’s similar to the line that I was given that b= ecause I signed a blue sheet in Singapore and didn’t stand up at the = microphone and publically object to something at the time – some how = my signature on the blue sheet indicated my acceptance and support of the issue in question. 

 

(To quote that)

 

PC2: The comment started because in the draft we ha= d an example that was assigning A:1::/32 as loopback interface for a router= . This is wrong (prefix length, documentation prefix,).

This was fixed in revision 2 of the WG draft, publi= shed in September 19th 2019. The closure of this comment was pre= sented by me personally in IETF Singapore. Please refer to the slides. In S= ingapore you were present (signed blue sheet) and did not had any comment about such closure.

 

 

This is interesting – so firstly – let = me state that because I was present in a meeting and signed a blue sheet to= say I was there – in no way indicates that I forgo the right to obje= ct after the meeting – and last I checked, signatures on a blue sheet are there to track attendance, not to track consensus.

 

 

So – can I make a humble request that we let peo= ple speak for themselves about what they actively support and want rather t= han trying to speak for others to bolster our case?  Because if the ca= se is so weak that we need to make claims on behalf of others – then there is no case at all.

 

Thanks

 

Andrew

--_000_AM6PR03MB50473D24C7ABA4E6CFC9603DEEA20AM6PR03MB5047eurp_-- From nobody Fri May 8 08:38:30 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67603A09EA for ; Fri, 8 May 2020 08:38:28 -0700 (PDT) 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=unavailable 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 lLpTQZB9FqV6 for ; Fri, 8 May 2020 08:38:25 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863AE3A0930 for <6man@ietf.org>; Fri, 8 May 2020 08:38:25 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id b18so1803801ilf.2 for <6man@ietf.org>; Fri, 08 May 2020 08:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QDuTjSwcwm9mI8XwaAq9tskSTZY2UF5YqoJ62jgpQZs=; b=ATw8xj6F41adKciwGLJwgifiRVcRbenBK6Y7kPGbohTWf+DL4y9cqDNLon0sB+yoOx VZ2/mUPUk2WHVBN9g5Eb/y+FjC6Dgkc+rbLXpVvcZygd+MQNEjgOFnTd+OFwz5LFctyx ADJJ/OAoEOOXc4g3mQUgff2XGWcbxyBtxz2GqWh2kw0u1I18q3m5AyBD4TE7Ji6eXJxw w5a6zgiIf6K4mFQA2sLzTT9RJOmO8MRegogdGv9DrvdZCz7k2bU5iizOqKzC4GRWDolW JtTtPkmDnQxXOSn1/cSwdGucs0WhlhC+MLv0uZN9qN7WcznS4WPFyRel/fbEzalinilU aEEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QDuTjSwcwm9mI8XwaAq9tskSTZY2UF5YqoJ62jgpQZs=; b=m/U/+ctFoRFLG7jUWjzehOSoa2TUnXkpyqUM9oWsNuxBx/ds090Qj93aoF8eLFRbf2 0b8C/GzBnG9Ajw0tqsWPAWIHueqU0KWHiwSM3cBYbss1t1NFhalsdpe2Linqw2oX8+sw slrsigRphLZMpuESW/PUwRCceo4w8DdZQr+uPp85cRfU7gCKPLMDo6XXHUIWv5aeg9a9 s+Syry1PcXy6Hce7fM9zdWNIVEe8ucl4MT3z7OQMN1/Wqs3itEsSdojhRjQ57/HPqmnQ V62Bz1RJVX4r89PeJZQo1q8cWz2uT2L+0vEFBdJAIlWWwaIJGinHew9PFuQ2rifLfNNY JqyQ== X-Gm-Message-State: AGi0PuZowzJ8XWhR0YJm9ryEPitOIpTIBEbkJmua0R9AhfNOa1mLNCOR k1kipHGnSy2rMyGxAdtSApy7Q/uugbKuC5sgPWKqLZxg X-Google-Smtp-Source: APiQypJiajpVX48ltpp1D3ObSA3wnthVci5632s7m6vYL+MBE8PNSvnbPf4t9sTyx6Bed58itayJlTJKDFglDydgm1Q= X-Received: by 2002:a05:6e02:e03:: with SMTP id a3mr3521542ilk.239.1588952304891; Fri, 08 May 2020 08:38:24 -0700 (PDT) MIME-Version: 1.0 References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> In-Reply-To: From: Tony Przygienda Date: Fri, 8 May 2020 08:36:59 -0700 Message-ID: Subject: Re: Routing Header Insertion To: "Joel M. Halpern" Cc: Robert Raszuk , 6man <6man@ietf.org>, "Darren Dukes (ddukes)" Content-Type: multipart/alternative; boundary="000000000000b2bdd605a524c9e4" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 15:38:29 -0000 --000000000000b2bdd605a524c9e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm mildly surprised the adult supervision didn't stop in here yet and put a tamper on the hot air blowing that seem to struggle with basic IETF principles before the WG complete deteriorates into an extension of a marketing organization ... RFC 1925 corollary 1) & 12) -- tony On Fri, May 8, 2020 at 7:14 AM Joel M. Halpern wrote: > No Robert, a vendor sending something to an interoperability test does > not prove that the feature is useful to anyone. There are many possible > interpretations / reasons / motivations. And for Darren, from Cisco, to > assert an interpretation for Juniper and its customers seems wrong to > me. If he did that to Ericsson, I would have reacted much more sharply > than Ron did. > > Yours, > Joel > > On 5/8/2020 6:33 AM, Robert Raszuk wrote: > > > > Hey Andrew, > > > > I don't think the point is on what one vendor desires or likes. The > > point is that they internally committed development resources to delive= r > > this functionality. They also asked one of their top talented > > TME Krzysiek to go and demo it. It carries a message. And all Zafar and > > others did was just sharing that message. > > > > It really does not matter that much Ron himself or on behalf of his > > company can jump on the lists stating that he does not like it. Even if > > Juniper marketing will not push it - even if they develop next cartoon > > mocking it - they will still likely check mark support tag on the RFPs. > > > > *All that proves that SRH insertion is a useful feature to customers.* > > And that's all what matters to some IETF decisions as part of that is > > community needs and support for extensions under standardization. > > > > Best, > > Robert. > > > > > > On Fri, May 8, 2020 at 12:16 PM Andrew Alston > > > > wrote: > > > > I do find it kinda bizarre that one vendor or an individual would > > jump to a conclusion and make statements about what another one > > desires =E2=80=93 surely it is up to the vendor that desires someth= ing to > > publicly state so and not for someone else to make statements on > > their behalf?____ > > > > __ __ > > > > I mean =E2=80=93 let=E2=80=99s be clear =E2=80=93 I have written a = partial SRv6 / SRv6-NP > > implementation into our DPDK lab testing stack =E2=80=93 I did it t= o verify > > certain things =E2=80=93 the only thing it further convinced me of= is that > > I will never run this in production =E2=80=93 in a million years = =E2=80=93 and I=E2=80=99d > > be rather concerned if someone went out there and said on the basis > > of the fact that I chose to test something =E2=80=93 I suddenly sup= ported or > > liked it. What that=E2=80=99s effectively saying is =E2=80=93 to t= est something is > > to support it =E2=80=93 that=E2=80=99s not the case. It=E2=80=99s = similar to the line that > > I was given that because I signed a blue sheet in Singapore and > > didn=E2=80=99t stand up at the microphone and publically object to = something > > at the time =E2=80=93 some how my signature on the blue sheet indic= ated my > > acceptance and support of the issue in question. ____ > > > > __ __ > > > > (To quote that)____ > > > > __ __ > > > > /PC2: The comment started because in the draft we had an example > > that was assigning A:1::/32 as loopback interface for a router. Thi= s > > is wrong (prefix length, documentation prefix,).//____/ > > > > /This was fixed in revision 2 of the WG draft, published in > > September 19^th 2019. The closure of this comment was presented by > > me personally in IETF Singapore. Please refer to the slides. In > > Singapore you were present (signed blue sheet) and did not had any > > comment about such closure.//____/ > > > > ///____/ > > > > ///____/ > > > > /This is interesting =E2=80=93 so firstly =E2=80=93 let me state th= at because I was > > present in a meeting and signed a blue sheet to say I was there =E2= =80=93 in > > no way indicates that I forgo the right to object after the meeting > > =E2=80=93 and last I checked, signatures on a blue sheet are there = to track > > attendance, not to track consensus.____/ > > > > /__ __/ > > > > __ __ > > > > So =E2=80=93 can I make a humble request that we let people speak f= or > > themselves about what they actively support and want rather than > > trying to speak for others to bolster our case? Because if the cas= e > > is so weak that we need to make claims on behalf of others =E2=80= =93 then > > there is no case at all.____ > > > > __ __ > > > > Thanks____ > > > > __ __ > > > > Andrew > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000b2bdd605a524c9e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm mildly surprised the adult supervision didn&#= 39;t stop in here yet and put a tamper on the hot air blowing that seem to = struggle with basic IETF principles before the WG complete deteriorates int= o an extension of a marketing organization ... RFC 1925 corollary 1) & = 12)

-- tony

On Fri, May 8, 2020 at 7:14 A= M Joel M. Halpern <jmh@joelhalper= n.com> wrote:
No Robert, a vendor sending something to an interoperability test does=
not prove that the feature is useful to anyone.=C2=A0 There are many possib= le
interpretations / reasons / motivations.=C2=A0 And for Darren, from Cisco, = to
assert an interpretation for Juniper and its customers seems wrong to
me.=C2=A0 If he did that to Ericsson, I would have reacted much more sharpl= y
than Ron did.

Yours,
Joel

On 5/8/2020 6:33 AM, Robert Raszuk wrote:
>
> Hey Andrew,
>
> I don't think the point is on what one vendor desires or likes. Th= e
> point is that they internally committed=C2=A0development resources to = deliver
> this functionality. They also asked one of their top talented
> TME=C2=A0Krzysiek to go and demo it. It carries a message. And all Zaf= ar and
> others did was just sharing that message.
>
> It really does not matter that much Ron himself or on behalf of his > company can jump on the lists stating that he=C2=A0does not like=C2=A0= it. Even if
> Juniper marketing will not push it - even if they=C2=A0develop=C2=A0ne= xt cartoon
> mocking=C2=A0it - they will still likely check mark support tag on the= RFPs.
>
> *All that proves that SRH insertion is a useful feature to=C2=A0custom= ers.*
> And that's all what matters to some IETF decisions as part of that= is
> community needs and support for extensions under standardization.
>
> Best,
> Robert.
>
>
> On Fri, May 8, 2020 at 12:16 PM Andrew Alston
> <Andrew.Alston@liquidtelecom.com
> <mailto:Andrew.Alston@liquidtelecom.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I do find it kinda bizarre that one vendor or an in= dividual would
>=C2=A0 =C2=A0 =C2=A0jump to a conclusion and make statements about what= another one
>=C2=A0 =C2=A0 =C2=A0desires =E2=80=93 surely it is up to the vendor tha= t desires something to
>=C2=A0 =C2=A0 =C2=A0publicly state so and not for someone else to make = statements on
>=C2=A0 =C2=A0 =C2=A0their behalf?____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0I mean =E2=80=93 let=E2=80=99s be clear =E2=80=93 I= have written a partial SRv6 / SRv6-NP
>=C2=A0 =C2=A0 =C2=A0implementation into our DPDK lab testing stack =E2= =80=93 I did it to verify
>=C2=A0 =C2=A0 =C2=A0certain things =E2=80=93 the only thing it further = convinced me =C2=A0of is that
>=C2=A0 =C2=A0 =C2=A0I will never run this in production =E2=80=93 in a = million years =E2=80=93 and I=E2=80=99d
>=C2=A0 =C2=A0 =C2=A0be rather concerned if someone went out there and s= aid on the basis
>=C2=A0 =C2=A0 =C2=A0of the fact that I chose to test something =E2=80= =93 I suddenly supported or
>=C2=A0 =C2=A0 =C2=A0liked it.=C2=A0 What that=E2=80=99s effectively say= ing is =E2=80=93 to test something is
>=C2=A0 =C2=A0 =C2=A0to support it =E2=80=93 that=E2=80=99s not the case= .=C2=A0 It=E2=80=99s similar to the line that
>=C2=A0 =C2=A0 =C2=A0I was given that because I signed a blue sheet in S= ingapore and
>=C2=A0 =C2=A0 =C2=A0didn=E2=80=99t stand up at the microphone and publi= cally object to something
>=C2=A0 =C2=A0 =C2=A0at the time =E2=80=93 some how my signature on the = blue sheet indicated my
>=C2=A0 =C2=A0 =C2=A0acceptance and support of the issue in question. __= __
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0(To quote that)____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0/PC2: The comment started because in the draft we h= ad an example
>=C2=A0 =C2=A0 =C2=A0that was assigning A:1::/32 as loopback interface f= or a router. This
>=C2=A0 =C2=A0 =C2=A0is wrong (prefix length, documentation prefix,).//_= ___/
>
>=C2=A0 =C2=A0 =C2=A0/This was fixed in revision 2 of the WG draft, publ= ished in
>=C2=A0 =C2=A0 =C2=A0September 19^th 2019. The closure of this comment w= as presented by
>=C2=A0 =C2=A0 =C2=A0me personally in IETF Singapore. Please refer to th= e slides. In
>=C2=A0 =C2=A0 =C2=A0Singapore you were present (signed blue sheet) and = did not had any
>=C2=A0 =C2=A0 =C2=A0comment about such closure.//____/
>
>=C2=A0 =C2=A0 =C2=A0///____/
>
>=C2=A0 =C2=A0 =C2=A0///____/
>
>=C2=A0 =C2=A0 =C2=A0/This is interesting =E2=80=93 so firstly =E2=80=93= let me state that because I was
>=C2=A0 =C2=A0 =C2=A0present in a meeting and signed a blue sheet to say= I was there =E2=80=93 in
>=C2=A0 =C2=A0 =C2=A0no way indicates that I forgo the right to object a= fter the meeting
>=C2=A0 =C2=A0 =C2=A0=E2=80=93 and last I checked, signatures on a blue = sheet are there to track
>=C2=A0 =C2=A0 =C2=A0attendance, not to track consensus.____/
>
>=C2=A0 =C2=A0 =C2=A0/__ __/
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0So =E2=80=93 can I make a humble request that we le= t people speak for
>=C2=A0 =C2=A0 =C2=A0themselves about what they actively support and wan= t rather than
>=C2=A0 =C2=A0 =C2=A0trying to speak for others to bolster our case?=C2= =A0 Because if the case
>=C2=A0 =C2=A0 =C2=A0is so weak that we need to make claims on behalf of= others =E2=80=93 then
>=C2=A0 =C2=A0 =C2=A0there is no case at all.____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Thanks____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Andrew
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> -------------------------------------------------------------------- >

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--000000000000b2bdd605a524c9e4-- From nobody Fri May 8 08:46:28 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79C13A0BAC for ; Fri, 8 May 2020 08:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aKHrXTcvHRkx for ; Fri, 8 May 2020 08:46:24 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 7E1D73A0B9F for <6man@ietf.org>; Fri, 8 May 2020 08:46:23 -0700 (PDT) Subject: RE: Routing Header Insertion Received: from dm5cch-d01.bellca.int.bell.ca (HELO DG1MBX04-WYN.bell.corp.bce.ca) ([198.235.102.31]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 08 May 2020 11:46:22 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 May 2020 11:46:21 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca ([fe80::4dcc:588c:b497:9730]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::4dcc:588c:b497:9730%22]) with mapi id 15.00.1497.006; Fri, 8 May 2020 11:46:21 -0400 From: "Voyer, Daniel" To: "Joel M. Halpern" , Robert Raszuk CC: 6man <6man@ietf.org>, "Darren Dukes (ddukes)" Thread-Topic: [EXT]Re: Routing Header Insertion Thread-Index: AQHWJI7Hu3BoqTQANkafRwglnWITvKidIyUAgAEZ/wCAAAT+AIAAPYyA///W2IA= Date: Fri, 8 May 2020 15:46:21 +0000 Message-ID: <5F668736-023A-4E3E-B55B-B952E0B68BB9@bell.ca> References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.25.1] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 15:46:27 -0000 DQoNCu+7v09uIDIwMjAtMDUtMDgsIDEwOjEzIEFNLCAiaXB2NiBvbiBiZWhhbGYgb2YgSm9lbCBN LiBIYWxwZXJuIiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqbWhAam9lbGhh bHBlcm4uY29tPiB3cm90ZToNCg0KICAgIE5vIFJvYmVydCwgYSB2ZW5kb3Igc2VuZGluZyBzb21l dGhpbmcgdG8gYW4gaW50ZXJvcGVyYWJpbGl0eSB0ZXN0IGRvZXMgDQogICAgbm90IHByb3ZlIHRo YXQgdGhlIGZlYXR1cmUgaXMgdXNlZnVsIHRvIGFueW9uZS4gIA0KDQpEVjpBcyBpZiB2ZW5kb3Jz IHdpbGwgdGFrZSB0aW1lICYgcmVzb3VyY2VzICgkJCQpIHRvIGRldmVsb3AgZmVhdHVyZXMgdGhh dCBtaWdodCBub3QgYmUgdXNlZnVsIHRvIGFueW9uZSBhbmQgdGhlbiBnbyB0byB0aGUgdHJvdWJs ZSBvZiBtYWtpbmcgcHVibGljIGludGVyb3AgcGFwZXIgPz8hIQ0KDQoNCkRhbg0KDQogICAgT24g NS84LzIwMjAgNjozMyBBTSwgUm9iZXJ0IFJhc3p1ayB3cm90ZToNCiAgICA+IA0KICAgID4gSGV5 IEFuZHJldywNCiAgICA+IA0KICAgID4gSSBkb24ndCB0aGluayB0aGUgcG9pbnQgaXMgb24gd2hh dCBvbmUgdmVuZG9yIGRlc2lyZXMgb3IgbGlrZXMuIFRoZSANCiAgICA+IHBvaW50IGlzIHRoYXQg dGhleSBpbnRlcm5hbGx5IGNvbW1pdHRlZCBkZXZlbG9wbWVudCByZXNvdXJjZXMgdG8gZGVsaXZl ciANCiAgICA+IHRoaXMgZnVuY3Rpb25hbGl0eS4gVGhleSBhbHNvIGFza2VkIG9uZSBvZiB0aGVp ciB0b3AgdGFsZW50ZWQgDQogICAgPiBUTUUgS3J6eXNpZWsgdG8gZ28gYW5kIGRlbW8gaXQuIEl0 IGNhcnJpZXMgYSBtZXNzYWdlLiBBbmQgYWxsIFphZmFyIGFuZCANCiAgICA+IG90aGVycyBkaWQg d2FzIGp1c3Qgc2hhcmluZyB0aGF0IG1lc3NhZ2UuDQogICAgPiANCiAgICA+IEl0IHJlYWxseSBk b2VzIG5vdCBtYXR0ZXIgdGhhdCBtdWNoIFJvbiBoaW1zZWxmIG9yIG9uIGJlaGFsZiBvZiBoaXMg DQogICAgPiBjb21wYW55IGNhbiBqdW1wIG9uIHRoZSBsaXN0cyBzdGF0aW5nIHRoYXQgaGUgZG9l cyBub3QgbGlrZSBpdC4gRXZlbiBpZiANCiAgICA+IEp1bmlwZXIgbWFya2V0aW5nIHdpbGwgbm90 IHB1c2ggaXQgLSBldmVuIGlmIHRoZXkgZGV2ZWxvcCBuZXh0IGNhcnRvb24gDQogICAgPiBtb2Nr aW5nIGl0IC0gdGhleSB3aWxsIHN0aWxsIGxpa2VseSBjaGVjayBtYXJrIHN1cHBvcnQgdGFnIG9u IHRoZSBSRlBzLg0KICAgID4gDQogICAgPiAqQWxsIHRoYXQgcHJvdmVzIHRoYXQgU1JIIGluc2Vy dGlvbiBpcyBhIHVzZWZ1bCBmZWF0dXJlIHRvIGN1c3RvbWVycy4qIA0KICAgID4gQW5kIHRoYXQn cyBhbGwgd2hhdCBtYXR0ZXJzIHRvIHNvbWUgSUVURiBkZWNpc2lvbnMgYXMgcGFydCBvZiB0aGF0 IGlzIA0KICAgID4gY29tbXVuaXR5IG5lZWRzIGFuZCBzdXBwb3J0IGZvciBleHRlbnNpb25zIHVu ZGVyIHN0YW5kYXJkaXphdGlvbi4NCiAgICA+IA0KICAgID4gQmVzdCwNCiAgICA+IFJvYmVydC4N CiAgICA+IA0KICAgID4gDQogICAgPiBPbiBGcmksIE1heSA4LCAyMDIwIGF0IDEyOjE2IFBNIEFu ZHJldyBBbHN0b24gDQogICAgPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSANCiAg ICA+IDxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+IHdyb3RlOg0KICAg ID4gDQogICAgPiAgICAgSSBkbyBmaW5kIGl0IGtpbmRhIGJpemFycmUgdGhhdCBvbmUgdmVuZG9y IG9yIGFuIGluZGl2aWR1YWwgd291bGQNCiAgICA+ICAgICBqdW1wIHRvIGEgY29uY2x1c2lvbiBh bmQgbWFrZSBzdGF0ZW1lbnRzIGFib3V0IHdoYXQgYW5vdGhlciBvbmUNCiAgICA+ICAgICBkZXNp cmVzIOKAkyBzdXJlbHkgaXQgaXMgdXAgdG8gdGhlIHZlbmRvciB0aGF0IGRlc2lyZXMgc29tZXRo aW5nIHRvDQogICAgPiAgICAgcHVibGljbHkgc3RhdGUgc28gYW5kIG5vdCBmb3Igc29tZW9uZSBl bHNlIHRvIG1ha2Ugc3RhdGVtZW50cyBvbg0KICAgID4gICAgIHRoZWlyIGJlaGFsZj9fX19fDQog ICAgPiANCiAgICA+ICAgICBfXyBfXw0KICAgID4gDQogICAgPiAgICAgSSBtZWFuIOKAkyBsZXTi gJlzIGJlIGNsZWFyIOKAkyBJIGhhdmUgd3JpdHRlbiBhIHBhcnRpYWwgU1J2NiAvIFNSdjYtTlAN CiAgICA+ICAgICBpbXBsZW1lbnRhdGlvbiBpbnRvIG91ciBEUERLIGxhYiB0ZXN0aW5nIHN0YWNr IOKAkyBJIGRpZCBpdCB0byB2ZXJpZnkNCiAgICA+ICAgICBjZXJ0YWluIHRoaW5ncyDigJMgdGhl IG9ubHkgdGhpbmcgaXQgZnVydGhlciBjb252aW5jZWQgbWUgIG9mIGlzIHRoYXQNCiAgICA+ICAg ICBJIHdpbGwgbmV2ZXIgcnVuIHRoaXMgaW4gcHJvZHVjdGlvbiDigJMgaW4gYSBtaWxsaW9uIHll YXJzIOKAkyBhbmQgSeKAmWQNCiAgICA+ICAgICBiZSByYXRoZXIgY29uY2VybmVkIGlmIHNvbWVv bmUgd2VudCBvdXQgdGhlcmUgYW5kIHNhaWQgb24gdGhlIGJhc2lzDQogICAgPiAgICAgb2YgdGhl IGZhY3QgdGhhdCBJIGNob3NlIHRvIHRlc3Qgc29tZXRoaW5nIOKAkyBJIHN1ZGRlbmx5IHN1cHBv cnRlZCBvcg0KICAgID4gICAgIGxpa2VkIGl0LiAgV2hhdCB0aGF04oCZcyBlZmZlY3RpdmVseSBz YXlpbmcgaXMg4oCTIHRvIHRlc3Qgc29tZXRoaW5nIGlzDQogICAgPiAgICAgdG8gc3VwcG9ydCBp dCDigJMgdGhhdOKAmXMgbm90IHRoZSBjYXNlLiAgSXTigJlzIHNpbWlsYXIgdG8gdGhlIGxpbmUg dGhhdA0KICAgID4gICAgIEkgd2FzIGdpdmVuIHRoYXQgYmVjYXVzZSBJIHNpZ25lZCBhIGJsdWUg c2hlZXQgaW4gU2luZ2Fwb3JlIGFuZA0KICAgID4gICAgIGRpZG7igJl0IHN0YW5kIHVwIGF0IHRo ZSBtaWNyb3Bob25lIGFuZCBwdWJsaWNhbGx5IG9iamVjdCB0byBzb21ldGhpbmcNCiAgICA+ICAg ICBhdCB0aGUgdGltZSDigJMgc29tZSBob3cgbXkgc2lnbmF0dXJlIG9uIHRoZSBibHVlIHNoZWV0 IGluZGljYXRlZCBteQ0KICAgID4gICAgIGFjY2VwdGFuY2UgYW5kIHN1cHBvcnQgb2YgdGhlIGlz c3VlIGluIHF1ZXN0aW9uLiBfX19fDQogICAgPiANCiAgICA+ICAgICBfXyBfXw0KICAgID4gDQog ICAgPiAgICAgKFRvIHF1b3RlIHRoYXQpX19fXw0KICAgID4gDQogICAgPiAgICAgX18gX18NCiAg ICA+IA0KICAgID4gICAgIC9QQzI6IFRoZSBjb21tZW50IHN0YXJ0ZWQgYmVjYXVzZSBpbiB0aGUg ZHJhZnQgd2UgaGFkIGFuIGV4YW1wbGUNCiAgICA+ICAgICB0aGF0IHdhcyBhc3NpZ25pbmcgQTox OjovMzIgYXMgbG9vcGJhY2sgaW50ZXJmYWNlIGZvciBhIHJvdXRlci4gVGhpcw0KICAgID4gICAg IGlzIHdyb25nIChwcmVmaXggbGVuZ3RoLCBkb2N1bWVudGF0aW9uIHByZWZpeCwpLi8vX19fXy8N CiAgICA+IA0KICAgID4gICAgIC9UaGlzIHdhcyBmaXhlZCBpbiByZXZpc2lvbiAyIG9mIHRoZSBX RyBkcmFmdCwgcHVibGlzaGVkIGluDQogICAgPiAgICAgU2VwdGVtYmVyIDE5XnRoIDIwMTkuIFRo ZSBjbG9zdXJlIG9mIHRoaXMgY29tbWVudCB3YXMgcHJlc2VudGVkIGJ5DQogICAgPiAgICAgbWUg cGVyc29uYWxseSBpbiBJRVRGIFNpbmdhcG9yZS4gUGxlYXNlIHJlZmVyIHRvIHRoZSBzbGlkZXMu IEluDQogICAgPiAgICAgU2luZ2Fwb3JlIHlvdSB3ZXJlIHByZXNlbnQgKHNpZ25lZCBibHVlIHNo ZWV0KSBhbmQgZGlkIG5vdCBoYWQgYW55DQogICAgPiAgICAgY29tbWVudCBhYm91dCBzdWNoIGNs b3N1cmUuLy9fX19fLw0KICAgID4gDQogICAgPiAgICAgLy8vX19fXy8NCiAgICA+IA0KICAgID4g ICAgIC8vL19fX18vDQogICAgPiANCiAgICA+ICAgICAvVGhpcyBpcyBpbnRlcmVzdGluZyDigJMg c28gZmlyc3RseSDigJMgbGV0IG1lIHN0YXRlIHRoYXQgYmVjYXVzZSBJIHdhcw0KICAgID4gICAg IHByZXNlbnQgaW4gYSBtZWV0aW5nIGFuZCBzaWduZWQgYSBibHVlIHNoZWV0IHRvIHNheSBJIHdh cyB0aGVyZSDigJMgaW4NCiAgICA+ICAgICBubyB3YXkgaW5kaWNhdGVzIHRoYXQgSSBmb3JnbyB0 aGUgcmlnaHQgdG8gb2JqZWN0IGFmdGVyIHRoZSBtZWV0aW5nDQogICAgPiAgICAg4oCTIGFuZCBs YXN0IEkgY2hlY2tlZCwgc2lnbmF0dXJlcyBvbiBhIGJsdWUgc2hlZXQgYXJlIHRoZXJlIHRvIHRy YWNrDQogICAgPiAgICAgYXR0ZW5kYW5jZSwgbm90IHRvIHRyYWNrIGNvbnNlbnN1cy5fX19fLw0K ICAgID4gDQogICAgPiAgICAgL19fIF9fLw0KICAgID4gDQogICAgPiAgICAgX18gX18NCiAgICA+ IA0KICAgID4gICAgIFNvIOKAkyBjYW4gSSBtYWtlIGEgaHVtYmxlIHJlcXVlc3QgdGhhdCB3ZSBs ZXQgcGVvcGxlIHNwZWFrIGZvcg0KICAgID4gICAgIHRoZW1zZWx2ZXMgYWJvdXQgd2hhdCB0aGV5 IGFjdGl2ZWx5IHN1cHBvcnQgYW5kIHdhbnQgcmF0aGVyIHRoYW4NCiAgICA+ICAgICB0cnlpbmcg dG8gc3BlYWsgZm9yIG90aGVycyB0byBib2xzdGVyIG91ciBjYXNlPyAgQmVjYXVzZSBpZiB0aGUg Y2FzZQ0KICAgID4gICAgIGlzIHNvIHdlYWsgdGhhdCB3ZSBuZWVkIHRvIG1ha2UgY2xhaW1zIG9u IGJlaGFsZiBvZiBvdGhlcnMg4oCTIHRoZW4NCiAgICA+ICAgICB0aGVyZSBpcyBubyBjYXNlIGF0 IGFsbC5fX19fDQogICAgPiANCiAgICA+ICAgICBfXyBfXw0KICAgID4gDQogICAgPiAgICAgVGhh bmtzX19fXw0KICAgID4gDQogICAgPiAgICAgX18gX18NCiAgICA+IA0KICAgID4gICAgIEFuZHJl dw0KICAgID4gDQogICAgPiANCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiBJRVRGIElQdjYgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QNCiAgICA+IGlwdjZAaWV0Zi5vcmcNCiAgICA+IEFkbWlu aXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwdjYNCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiANCg0KICAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAg SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQogICAgaXB2NkBpZXRmLm9yZw0K ICAgIEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwdjYNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KICAgIEV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxp bmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZl YyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQo= From nobody Fri May 8 09:16:35 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EF23A0C45 for ; Fri, 8 May 2020 09:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4REqoOcIwf5 for ; Fri, 8 May 2020 09:16:29 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67323A0C3C for ; Fri, 8 May 2020 09:16:28 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jX5fe-0000KUC; Fri, 8 May 2020 18:16:18 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: Routing Header Insertion From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> <5F668736-023A-4E3E-B55B-B952E0B68BB9@bell.ca> In-reply-to: Your message of "Fri, 8 May 2020 15:46:21 +0000 ." <5F668736-023A-4E3E-B55B-B952E0B68BB9@bell.ca> Date: Fri, 08 May 2020 18:16:16 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 16:16:31 -0000 > DV:As if vendors will take time & resources ($$$) to develop features > that might not be useful to anyone and then go to the trouble of > making public interop paper ??!! Maybe people can keep these kinds of discussions out 6man. This is a complete waste of my time and, I'm sure, many others. From nobody Fri May 8 09:20:50 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC273A0B9D for ; Fri, 8 May 2020 09:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H08y6gw9Az9i for ; Fri, 8 May 2020 09:20:47 -0700 (PDT) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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 4124B3A084F for <6man@ietf.org>; Fri, 8 May 2020 09:20:47 -0700 (PDT) Received: by mail-wr1-f45.google.com with SMTP id 50so2030430wrc.11 for <6man@ietf.org>; Fri, 08 May 2020 09:20:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DR20ZjMp+CWwGetOtwlq0qXh56xPQJeQjrtO+DkskKo=; b=XZTeTQjZ2gqR0V/VrniAYmV8TQe2Dq2O3jFWLvfztKvuQYP1gN/VIii+2V4jDjCs1f y8hr16nf0+8KPsqG9a6l/0+lJE8VDtLIOEXEjzwAVBnvG+Yqh+UBbJv1Lqml0RRWmZll 22Rl8TNEg3TirMYtkKbmhwO9Dl1NWznx1wQYaIk+ZTEN3HWlLms2ScrabOWs1zJ8t24h j83FY7gcn1zVozQ2/XZwrfUGV9m9FobcKfdxlj5XOdHf0f20+QQGfkORkQN+z8F57K21 dhpqJabmqp9gZeC8HUvCy7GvXhbLiFLpK8fIMoPkfz5qBnC6qJDJTbuXi++g5HQ39G0D 3WhQ== X-Gm-Message-State: AGi0PuYbMFdLneeEq4xCaYNCuBIEO4cD27sEQfdO7Ix2qoYFYIx/PRvr a5KNelkzU+ITs10hOohG7Ao6m8JMdVrABubPeMQ= X-Google-Smtp-Source: APiQypKExeDfvHrBVQmhFnCuQ9dQpFGSprG1pHm2RmRARQnmPI1Y8FRXBL4xstVTY1b6doLMdBWsa+7o4qOd78Psdr8= X-Received: by 2002:a5d:6646:: with SMTP id f6mr3718657wrw.318.1588954845614; Fri, 08 May 2020 09:20:45 -0700 (PDT) MIME-Version: 1.0 References: <9865489e-ad29-5eb0-0dd8-370812d92b12@gmail.com> <3b982733-f18c-ab20-bd0d-39b7f12c14e1@gmail.com> In-Reply-To: <3b982733-f18c-ab20-bd0d-39b7f12c14e1@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 8 May 2020 09:20:34 -0700 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Brian E Carpenter Cc: 6MAN <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 16:20:49 -0000 At Thu, 7 May 2020 08:54:43 +1200, Brian E Carpenter wrote: > > do you mean that we should be able to expect the above > > "what it means" happens without the help of this draft? > > In the ideal world, yes. But in the real world I think it's > better to publish your draft, to avoid future misunderstandings. Ah, okay, thanks for the clarification (I actually thought you might be trying to say the opposite:-). It's nice to know there's at least someone other than the authors seeing the need for publishing it. -- JINMEI, Tatuya From nobody Fri May 8 09:48:05 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E8A3A0DB0 for ; Fri, 8 May 2020 09:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XHQCY2jsmL-H for ; Fri, 8 May 2020 09:47:24 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 7F6B83A0D98 for ; Fri, 8 May 2020 09:47:22 -0700 (PDT) Subject: RE: Routing Header Insertion Received: from dm5cch-d01.bellca.int.bell.ca (HELO DG1MBX02-WYN.bell.corp.bce.ca) ([198.235.102.31]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 08 May 2020 12:47:00 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX02-WYN.bell.corp.bce.ca (2002:8eb6:120c::8eb6:120c) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 May 2020 12:46:59 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca ([fe80::4dcc:588c:b497:9730]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::4dcc:588c:b497:9730%22]) with mapi id 15.00.1497.006; Fri, 8 May 2020 12:47:00 -0400 From: "Voyer, Daniel" To: Philip Homburg , "ipv6@ietf.org" Thread-Topic: [EXT]Re: Routing Header Insertion Thread-Index: AQHWJVQGtHwW9Bd5dkGiG1QCkJC0UaieZeyA Date: Fri, 8 May 2020 16:47:00 +0000 Message-ID: <7AC1D99D-D2EE-4B8D-BF49-71A09FFB16EB@bell.ca> References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> <5F668736-023A-4E3E-B55B-B952E0B68BB9@bell.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.25.1] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 16:47:35 -0000 SWYgaXQncyBhIHdhc3RlIG9mIHlvdXIgdGltZSAuLi4ganVzdCBkb24ndCBwcm9jZXNzIGl0IC0g d2h5IGRvIHdlIGV2ZW4gbmVlZCB0byBrbm93IHRoYXQgPyENCg0KVGhlIGNvbnZlcnNhdGlvbiBz dGFydGVkIHRvIHNpZGUtdHJhY2sgbG9uZyBhZ28gDQoNCu+7v09uIDIwMjAtMDUtMDgsIDEyOjE2 IFBNLCAicGNoLWI5RDNDQjBGNUB1LTEucGhpY29oLmNvbSBvbiBiZWhhbGYgb2YgUGhpbGlwIEhv bWJ1cmciIDxwY2gtYjlEM0NCMEY1QHUtMS5waGljb2guY29tIG9uIGJlaGFsZiBvZiBwY2gtaXB2 Ni1pZXRmLTZAdS0xLnBoaWNvaC5jb20+IHdyb3RlOg0KDQogICAgPiBEVjpBcyBpZiB2ZW5kb3Jz IHdpbGwgdGFrZSB0aW1lICYgcmVzb3VyY2VzICgkJCQpIHRvIGRldmVsb3AgZmVhdHVyZXMNCiAg ICA+IHRoYXQgbWlnaHQgbm90IGJlIHVzZWZ1bCB0byBhbnlvbmUgYW5kIHRoZW4gZ28gdG8gdGhl IHRyb3VibGUgb2YNCiAgICA+IG1ha2luZyBwdWJsaWMgaW50ZXJvcCBwYXBlciA/PyEhDQoNCiAg ICBNYXliZSBwZW9wbGUgY2FuIGtlZXAgdGhlc2Uga2luZHMgb2YgZGlzY3Vzc2lvbnMgb3V0IDZt YW4uIFRoaXMgaXMgYSANCiAgICBjb21wbGV0ZSB3YXN0ZSBvZiBteSB0aW1lIGFuZCwgSSdtIHN1 cmUsIG1hbnkgb3RoZXJzLg0KDQoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBFeHRl cm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0 YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5z IGV0IGRvY3VtZW50cyBqb2ludHMNCg0KDQo= From nobody Fri May 8 09:58:04 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26003A0D0C for ; Fri, 8 May 2020 09:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y_TliiGMdP_H for ; Fri, 8 May 2020 09:57:59 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FCF3A0B43 for <6man@ietf.org>; Fri, 8 May 2020 09:57:58 -0700 (PDT) Received: from [IPv6:2a01:79d:53aa:d30:349a:8868:9581:5802] (unknown [IPv6:2a01:79d:53aa:d30:349a:8868:9581:5802]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 3376E4E11A6A; Fri, 8 May 2020 16:57:58 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 Date: Fri, 8 May 2020 18:57:53 +0200 Message-Id: References: Cc: 6MAN <6man@ietf.org> In-Reply-To: To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: iPhone Mail (17F5054h) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 16:58:02 -0000 > On 8 May 2020, at 18:21, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >=20 > =EF=BB=BFAt Thu, 7 May 2020 08:54:43 +1200, > Brian E Carpenter wrote: >=20 >>> do you mean that we should be able to expect the above >>> "what it means" happens without the help of this draft? >>=20 >> In the ideal world, yes. But in the real world I think it's >> better to publish your draft, to avoid future misunderstandings. >=20 > Ah, okay, thanks for the clarification (I actually thought you might > be trying to say the opposite:-). It's nice to know there's at least > someone other than the authors seeing the need for publishing it. What I am struggling with is what can we possibly hope to achieve by publish= ing this draft... Cheers=20 Ole= From nobody Fri May 8 10:19:00 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54353A0B6F for ; Fri, 8 May 2020 10:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Mn9Kp-x-iFg for ; Fri, 8 May 2020 10:18:54 -0700 (PDT) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 54AB83A0DA2 for <6man@ietf.org>; Fri, 8 May 2020 10:18:24 -0700 (PDT) Received: by mail-wm1-f54.google.com with SMTP id y24so11442450wma.4 for <6man@ietf.org>; Fri, 08 May 2020 10:18:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+a+aDwong069rm9K3aPNzzYi11e61TDrvk6AOje5ECk=; b=sOwk9WISm4kRpJ7gCPJJUSHY0eizKAJJDa1mgzovmOnNaFMaS0fpKmC4Jenb90J/8G euaUP2382pN6FpA7ebj9A1bwucRtT04AKgElxOsTtol+yUjXSami142bMWmWdV7NPc0H WuQcUeLIFNxfa+Ysng+mvpwE7JBSP0q3B/hfTAal7cZxpElMOjkQv9AIUZsD/MxunEyv pY4fLnBw2nSbpUVvvkJg/dx9X2kRviE2PrPQF26Lv74Pv9WauwllCQUUHWqF7LiP6mRl uthIz6Ar8kzhVdTQivJWgQCqOWPogtQibC5UNW7Gy+kNrKTYQwDdn0EUfixBlHhQ4UxM Q49A== X-Gm-Message-State: AGi0PuaN70OcpoeiFH/EFOP+qBdHbAlx0302pYk08cEHYXr4KQbQ8tK9 yeYFbH/04OEVnoMfsBD0woQPU2EUyzrCEwOHetOxYOFv X-Google-Smtp-Source: APiQypK/nXJJfislqG4oIGKtpbLtrMdJpnxZFCPYykzImb1Q/eOhEboUUBy1z+cG0N679ENRfGG4zyv9tC9GOPqwrCo= X-Received: by 2002:a1c:b354:: with SMTP id c81mr9777965wmf.136.1588958302618; Fri, 08 May 2020 10:18:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 8 May 2020 10:18:10 -0700 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Ole Troan Cc: 6MAN <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 17:18:58 -0000 At Fri, 8 May 2020 18:57:53 +0200, Ole Troan wrote: > >> In the ideal world, yes. But in the real world I think it's > >> better to publish your draft, to avoid future misunderstandings. > > > > Ah, okay, thanks for the clarification (I actually thought you might > > be trying to say the opposite:-). It's nice to know there's at least > > someone other than the authors seeing the need for publishing it. > > What I am struggling with is what can we possibly hope to achieve by publishing this draft... In case you missed it, I explained *my hope* in my earlier message: https://mailarchive.ietf.org/arch/msg/ipv6/GRys9-16AgxCKw8X_Dt-9V4VimM/ For example, if we had had this draft (or even better, published it as an RFC) before the discussion of draft-ietf-spring-srv6-network-programming, we could have had more constructive discussions on why its approach is safe/acceptable even if it would violate the sense of RFC8200 (and the hypothetical RFC based on this draft) from the beginning, instead of spending a lot of our time for not very constructive ones regarding whether it actually conforms to RFC8200 (and therefore no further consideration is necessary). Of course, it's just my hope. I wouldn't be surprised if someone else is more pessimistic. My other hope is that we can have a rough consensus on a more optimistic view on this as a wg and will try to reach it, but ultimately it's up to the wg. -- JINMEI, Tatuya From nobody Fri May 8 10:47:56 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735BB3A0C3A for ; Fri, 8 May 2020 10:47:52 -0700 (PDT) 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 sRealdE-W3Vk for ; Fri, 8 May 2020 10:47:48 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 D8BCA3A0BB8 for <6man@ietf.org>; Fri, 8 May 2020 10:47:47 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id e9so2613144iok.9 for <6man@ietf.org>; Fri, 08 May 2020 10:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HcDxr9bfn0uQEKjadB4W6as0hshO0rk3WXbXFZQ1TWI=; b=K3AVQnEcOO2uwNt9E82b7yfRO02wFRD4UmgWNRlQg/ixDzLwJbgc/GSfp/cMHzEYnp PHMU1ZTHr1AYjK9FrnmFrawv6nCBpwJ7641MFStGC4tNCmJrr6HYiPMtxXOkfhVp0/ur 2auEtXVPfoeVuy/oMPPmfiZo3O52pRw/ob8V/MoHSnMwJuo4AvlzhDITDF0dH78b7Aot IkNw4xgzZJLkZR520+UZ85cPF+Tcwm4XvNv++UTndWnFRT/dLeo/XmiV5u5id+r6OOO0 k/V+jbtOe9pckscWU5UbHuotYfpYDLzyGXdK70j9btO+ISgurVhTEf5R84snIpd89l0z qa7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HcDxr9bfn0uQEKjadB4W6as0hshO0rk3WXbXFZQ1TWI=; b=HzwKRaJX0+XAOo4/IsmKEnL5amcxkXcpH/Tm/s+eqb9s0v80iuSTsbG3Kr2jwGIdPY LSa+3US4XEsyZkjZLdZnAeXolTDbgiLFqiGr+FIQjxLzfZL5+/G3XwdwT/OTGtbl7102 ReZqG6qhuXcYUo+JlLZ1WDTDE4t/48Db1S+ZfVST04SYRZlGqgc/eTzK3Bir5kZlc+Kh t5eckRAKdloPb4KHF5AtIXXdgj2Md/59FrpGQyXgBw5FwLvn5dfHP9CY5LbWKk1Hao6W elHUMtnhQ0gT5q0/fjbp3lUbJW3NBqgKGjki9C/kzCa6mNrzmeBMhBnq4kovji/BlBvZ Shig== X-Gm-Message-State: AGi0PuY/JS8Xz9z3BLha5J1ZcXzyYCcKHSwjHXWv9CC7axkhWYzH2BiC KFK1L3PvWGE+6F9mrSU3PWEQ9PP2zX1OmHvm+Xg= X-Google-Smtp-Source: APiQypKmcnRQN139nLQtRDenVKMs4hug3AE+1M0Zb4INkKHps+05z8NU5s0uJ6MRkT76gMSRO3y6sWDlzUQh744JcVw= X-Received: by 2002:a5d:8b57:: with SMTP id c23mr3724337iot.88.1588960066980; Fri, 08 May 2020 10:47:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Fri, 8 May 2020 13:47:35 -0400 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: 6MAN <6man@ietf.org>, Ole Troan Content-Type: multipart/alternative; boundary="0000000000005ad0bb05a5269862" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 17:47:53 -0000 --0000000000005ad0bb05a5269862 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 8, 2020 at 1:19 PM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Fri, 8 May 2020 18:57:53 +0200, > Ole Troan wrote: > > > >> In the ideal world, yes. But in the real world I think it's > > >> better to publish your draft, to avoid future misunderstandings. > > > > > > Ah, okay, thanks for the clarification (I actually thought you might > > > be trying to say the opposite:-). It's nice to know there's at least > > > someone other than the authors seeing the need for publishing it. > > > > What I am struggling with is what can we possibly hope to achieve by > publishing this draft... > > In case you missed it, I explained *my hope* in my earlier message: > https://mailarchive.ietf.org/arch/msg/ipv6/GRys9-16AgxCKw8X_Dt-9V4VimM/ > > For example, if we had had this draft (or even better, published it as > an RFC) before the discussion of > draft-ietf-spring-srv6-network-programming, > we could have had more constructive discussions on why its approach is > safe/acceptable even if it would violate the sense of RFC8200 (and the > hypothetical RFC based on this draft) from the beginning, instead of > spending a lot of our time for not very constructive ones regarding > whether it actually conforms to RFC8200 (and therefore no further > consideration is necessary). > > Of course, it's just my hope. I wouldn't be surprised if someone else > is more pessimistic. My other hope is that we can have a rough > consensus on a more optimistic view on this as a wg and will try to > reach it, but ultimately it's up to the wg. > > -- > JINMEI, Tatuya Gyan> That is the real crux of the why? as to this update to help with the constant battle with Spring on in flight EH insertion. There maybe other cases where tightening the RFC 8200 verbiage maybe helpful but the SRv6 is the only one so far. The other one is with TI-LFA with rtgwg with EH insertion at the PLR node. In the SRv6 programming draft and with TI-LFA the workaround was to do encapsulation + EH insertion to accommodate both sides. At the end of last year and into this year it boiled down to the PSP and Spring after many discussions would not budge on removal of PSP as a violation. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --0000000000005ad0bb05a5269862 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, May 8, 2020 at 1:19 PM =E7=A5=9E=E6=98=8E=E9=81=94= =E5=93=89 <jinmei@wide.ad.jp>= ; wrote:
At Fri, 8 May 2020 18:57:5= 3 +0200,
Ole Troan <otr= oan@employees.org> wrote:

> >> In the ideal world, yes. But in the real world I think it'= ;s
> >> better to publish your draft, to avoid future misunderstandin= gs.
> >
> > Ah, okay, thanks for the clarification (I actually thought you mi= ght
> > be trying to say the opposite:-).=C2=A0 It's nice to know the= re's at least
> > someone other than the authors seeing the need for publishing it.=
>
> What I am struggling with is what can we possibly hope to achieve by p= ublishing this draft...

In case you missed it, I explained *my hope* in my earlier message:
https://mailarchive.ietf.org/= arch/msg/ipv6/GRys9-16AgxCKw8X_Dt-9V4VimM/

For example, if we had had this draft (or even better, published it as
an RFC) before the discussion of draft-ietf-spring-srv6-network-programming= ,
we could have had more constructive discussions on why its approach is
safe/acceptable even if it would violate the sense of RFC8200 (and the
hypothetical RFC based on this draft) from the beginning, instead of
spending a lot of our time for not very constructive ones regarding
whether it actually conforms to RFC8200 (and therefore no further
consideration is necessary).

Of course, it's just my hope.=C2=A0 I wouldn't be surprised if some= one else
is more pessimistic.=C2=A0 My other hope is that we can have a rough
consensus on a more optimistic view on this as a wg and will try to
reach it, but ultimately it's up to the wg.

--
JINMEI, Tatuya

Gy= an> That is the real crux of the why? as to this update to help with the= constant battle with Spring on in flight EH insertion.=C2=A0 There maybe o= ther cases where tightening the RFC 8200 verbiage maybe helpful but the SRv= 6 is the only one so far.=C2=A0 The other one is with TI-LFA with rtgwg wit= h EH insertion at the PLR node.=C2=A0 In the SRv6 programming draft and wit= h TI-LFA the workaround was to do encapsulation + =C2=A0EH insertion to acc= ommodate both sides.=C2=A0 At the end of last year and into this year it bo= iled down to the PSP and Spring after many discussions would not budge on r= emoval of PSP as a violation. =C2=A0

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--
--0000000000005ad0bb05a5269862-- From nobody Fri May 8 11:04:03 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238B53A0BCD for ; Fri, 8 May 2020 11:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1OFf1NLrueS for ; Fri, 8 May 2020 11:03:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33C43A0BB6 for ; Fri, 8 May 2020 11:03:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jX7Lf-0000KbC; Fri, 8 May 2020 20:03:47 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: In-reply-to: Your message of "Fri, 8 May 2020 18:57:53 +0200 ." Date: Fri, 08 May 2020 20:03:45 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 18:04:01 -0000 > What I am struggling with is what can we possibly hope to achieve > by publishing this draft... It seems to me that the interpretation of RFC 8200 that an intermediate router in the context of a routing header may arbitrarily insert, delete, or modify any extension headers, makes routing headers a very dangerous concept. To the extent that this is obviously wrong, it make sense to adopt Fernado's erratum (https://www.rfc-editor.org/errata/eid6003). However, it can be said that this particular case was never discussed before RFC 8200 was published. In that case the erratum can be rejected, and we can see if this draft reaches (rough) consensus. Independent of merrits of segment routing, allowing arbitrary inserts, deletes, or modifications is not a good thing. From nobody Fri May 8 12:13:42 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1D33A0C7E for ; Fri, 8 May 2020 12:13:40 -0700 (PDT) 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 ciZVHjl9bXR8 for ; Fri, 8 May 2020 12:13:38 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 6E06A3A0879 for ; Fri, 8 May 2020 12:13:38 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id k6so2897268iob.3 for ; Fri, 08 May 2020 12:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VADTHS2423x87yEZsmYfRJdI6DwUwTQbtx0LDYPF6Ok=; b=hwStAFa0O2b2IY1GOkTOCZb6ytbsh0fo9haJs7oBqldEN0cFZ03eDoOJDE0Dpkkwtf qs4pn6d9ruM+rIv2yosdk29+DJpa2loSjTzU5B5Xm9XC2X1qh7dx2WbOrZRZ/N39naNU zEOl3cyJGEyBq4ngz/uOcLzmbgXTH/Y+TxEASGzO+yBnh5Kxgc2iMYBawq5LWhPgKbih 8r4BnJa90czFzMV/47P/FPHDiMao5Esrv8lmhpB6lB059OxGZOrHTXLZe5/nz2GhdDMf gwR3Gs1h3Xhx9gQc7dGnlNU5mq9g850mH1zjRgDvCIVRUyK+FlDLysInoRb/e5Bck4wH +raQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VADTHS2423x87yEZsmYfRJdI6DwUwTQbtx0LDYPF6Ok=; b=hwNx9aH5fLANBXREHI8DTEEhgr4fu29fEge1lBIC/c0du4FUxLDGfhNqtlqPBt7x0g 99LunZX9uul07vjsEeegGrJiK9uZSurPDf3CJi8gCa3QekmE9JLAD9jwD7pGAbrK04Do atBgHUu1GwGwW8w57P19lQ/kuG++tUCbaOd7FZ+kYXZFCdUJ+kxVV9x0QFsgBMLWEkfU eClffzGwh4Ud8jCLw+Jibu72AQkPHR7ydyUiHqwm9/ACTkwolADqKXVxfzYO2gS88l4P TyzTLkiFK1yBl83j8AfNmk+wufHsBifQ/JM2l5bmRMRA1ychrJtAfSQRFa3AGblUtbRT xzXA== X-Gm-Message-State: AGi0PuaEb4RzFqAM461tS5x8toxAf2W6s287t96yaCPC2E74/P4NRerX 1/mVNHaN9UQvQJxRihKRcSPrBg2VDJyM7keFUlGOvXOLy28= X-Google-Smtp-Source: APiQypIu8VXefuBLUaHgyHX7ERn2WmBFXzfM+105Sb3tYl0M91GMTjnyVFdFsUcz96SQ/ylEL4oj8e+mFIxj72RmtAU= X-Received: by 2002:a5d:8a10:: with SMTP id w16mr3059722iod.95.1588965217409; Fri, 08 May 2020 12:13:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Fri, 8 May 2020 15:13:26 -0400 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Philip Homburg Cc: ipv6@ietf.org Content-Type: multipart/alternative; boundary="00000000000058212905a527cb4a" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 19:13:41 -0000 --00000000000058212905a527cb4a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was digging through the many threads with Spring and here is excerpt from my reply to Darren Dukes and Jingrong which states exact area where the issue arises with EH removal with PSP and the area of confusion. I wonder maybe we can add this example in a stick diagram in the update so it=E2=80= =99s crystal clear. Excerpt below: The key is that to the PSP node the incoming SL is 1 - but after the final DA is copied the SL pointer is updated so the outgoing SL is 0 - this satisfying the pseudocode criteria and RFC 8200 to remove the SRH since the final DA is now set. If you look at this before the packet is received then it appears as in flight and not final destination so it may appear not in RFC 8200 conformance which has been the contention all along. However, if you look at it after PSP node has received and processed the PSP function psuedocode you are now in RFC 8200 conformance. Kind regards Gyan On Fri, May 8, 2020 at 2:04 PM Philip Homburg < pch-ipv6-ietf-6@u-1.phicoh.com> wrote: > > What I am struggling with is what can we possibly hope to achieve > > by publishing this draft... > > It seems to me that the interpretation of RFC 8200 that an intermediate > router in the context of a routing header may arbitrarily insert, delete, > or > modify any extension headers, makes routing headers a very dangerous > concept. > > To the extent that this is obviously wrong, it make sense to adopt > Fernado's > erratum (https://www.rfc-editor.org/errata/eid6003). > > However, it can be said that this particular case was never discussed > before > RFC 8200 was published. In that case the erratum can be rejected, and we > can see if this draft reaches (rough) consensus. > > Independent of merrits of segment routing, allowing arbitrary inserts, > deletes, > or modifications is not a good thing. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --00000000000058212905a527cb4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was digging through the many threads with Spring a= nd here is excerpt from my reply to Darren Dukes and Jingrong which states = exact area where the issue arises with EH removal with PSP and the area of = confusion.=C2=A0 I wonder maybe we can add this example in a stick diagram = in the update so it=E2=80=99s crystal clear.
<= br>
Excerpt below:

=
The key is that to the PSP node the incoming=C2=A0SL=C2=A0is=C2=A01=C2=A0- but after the = final DA is copied the=C2=A0SL=C2=A0pointer is updated s= o =C2=A0the outgoing=C2=A0SL=C2=A0is 0 =C2=A0- this sati= sfying the pseudocode criteria and RFC 8200 to remove the SRH since the fin= al DA is now set. =C2=A0


If you look at this before the packet is= received then it appears as in flight and not final destination so it may = appear not in RFC 8200 conformance which has been the contention all along.= =C2=A0 However, =C2=A0if you look at it after PSP node has received and pro= cessed the PSP function psuedocode you are now in RFC 8200 conformance.

Kind=C2=A0regards

Gyan
=

On Fri, May 8, 2020 at 2:04 PM Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> wrote:=
> What I am struggling with is = what can we possibly hope to achieve
> by publishing this draft...

It seems to me that the interpretation of RFC 8200 that an intermediate
router in the context of a routing header may arbitrarily insert, delete, o= r
modify any extension headers, makes routing headers a very dangerous concep= t.

To the extent that this is obviously wrong, it make sense to adopt Fernado&= #39;s
erratum (https://www.rfc-editor.org/errata/eid6003).
However, it can be said that this particular case was never discussed befor= e
RFC 8200 was published. In that case the erratum can be rejected, and we can see if this draft reaches (rough) consensus.

Independent of merrits of segment routing, allowing arbitrary inserts, dele= tes,
or modifications is not a good thing.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--
<= div dir=3D"ltr">

Gyan= =C2=A0 Mishra

Network Engineering & Technology= =C2=A0

Verizon=C2=A0

Silver Spring, MD 20= 904

Phone: 301 502-1347

<= font size=3D"1" color=3D"#000000" face=3D"georgia, serif">Email: gyan.s.mishra@verizon.= com



--00000000000058212905a527cb4a-- From nobody Fri May 8 12:21:28 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929183A0DF5 for ; Fri, 8 May 2020 12:21:25 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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, 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=Sv6crV1Z; dkim=pass (1024-bit key) header.d=juniper.net header.b=aQ1qawJM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmzRuVc-CMsm for ; Fri, 8 May 2020 12:21:23 -0700 (PDT) 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 438813A0DEE for ; Fri, 8 May 2020 12:21:23 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 048JIbrm022485; Fri, 8 May 2020 12:21:20 -0700 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=KxSylRqMOKa8XmciIrAY7w9dV2KmjUJQmlHoQZxJyNk=; b=Sv6crV1ZE1mczu/nErgTVhi9AtdtG5723vGhK/fABBgH11968KK7DQhHeTK0bAPyp3Sy wajCtaguQR32yg6ghdF0BN5LC/WG546Tch+iTvy2Uuqpb9wbxOQYRq8TXMJp1dbSwwZY a+fohF6c+5O260WsDaxEsaHCoMCvuu4u82rYDp2z14DhHAvfa4ZaNBuwpJdp4wQtz5eV qoSUDofrrO/m4gwRtH0sr9UjMl68AB1jIiqFEjF1gWrtwTH9tK29JZKS+4NjHrR2+/Nd bteZ2J5/NrDUnQovM6PY9HLKYqjJ4sYS2VlzP/QPHAb1ftTLlz523UYUqIL4e2heQMWr kQ== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2169.outbound.protection.outlook.com [104.47.56.169]) by mx0b-00273201.pphosted.com with ESMTP id 30vte9sycn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 May 2020 12:21:20 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=geXKNeAF5459+8yutT9x8VbyCba2cG6/y7jGxeMA/mDZYrOFpNDx+v8km4lqzIjOvwF6eTJwBw8Nxt2t6H7Be+Upl+qfL8QFKhDBybLE5w0YcG/uwKUs2tlEJkQgqp75jNDCWHxPf8oNj2jTMp8a7SatdyIIki9ThnaqqU5VwNwA2eHda2Rbkz9j8lEwAtdu1FAuckbv9XKnzlP3ff5WbmSMisFy8OM+pgQbqOCpwMix1ipiI8Nrp3+QB7uZCMW4RjaVy1/fMofIkj8Zh/XXtCTSDqB5o/y+RyR16FjA2nDdGndZ1l1hOBj55z6v0eZEdC/MvK9blBNqzgMhgned+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KxSylRqMOKa8XmciIrAY7w9dV2KmjUJQmlHoQZxJyNk=; b=TNaVilGcVr2ZGgnl9Ec6YudWCHJQ2BXMgf3/LlsOBXYknafUOo8Wr6uGQDES9gJ4pyjx8QglNjJuTAPXRxvIcvylUjL32ySAf+nbvzQvmzhpVpyBvmDQ3BNpIB5SGl2Xw/Uuci1lsJe7UXDinm4ljtsitz36nZAJ/V+4zqPHgE6Lhnf55CrgqOZnUGSeNYUpC5dZqP0dn+GsFWoPyx/yEhV3Kd6FM7amRSNLLPHYGse7wPbkMJYvMWYFb4TNbambO7yv3owDAjo+XS8B3hGIsYJAn3QCrtsOIIqItOl/w+nvlUO0lEOZJo55bonm4+66P6SNTMCyJtLbYvHl2xFESQ== 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=KxSylRqMOKa8XmciIrAY7w9dV2KmjUJQmlHoQZxJyNk=; b=aQ1qawJMmqt8O1QS1ow9tVtZ9McW94wajLHstCCtImMBxpSM3oZYxtoOZva+yrOtSPeinC7xAQHDWlv0ElXdsYghzqtVKT/yczznDfdJReLnyBMxvikB5laAIjfNTBD34l060dD2OaLq3EaATrR+x9nD3cVRRnyhRqWVFB0CTro= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB5161.namprd05.prod.outlook.com (2603:10b6:5:30::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.11; Fri, 8 May 2020 19:21:10 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::c020:3bf5:7230:75e3%4]) with mapi id 15.20.2979.028; Fri, 8 May 2020 19:21:10 +0000 From: Ron Bonica To: Philip Homburg , "ipv6@ietf.org" Subject: RE: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 Thread-Topic: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 Thread-Index: AQHWI0Ntd7vo7gMvDEaZQokI4IPMZ6iaXE+AgAEndQCAAAbXgIAC2BEAgAAKbYCAABKVloAADw6g Date: Fri, 8 May 2020 19:21: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_SetDate=2020-05-08T19: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=894bc5c5-2180-4345-ab37-e44852c20237; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action authentication-results: u-1.phicoh.com; dkim=none (message not signed) header.d=none; u-1.phicoh.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c22a47b5-9187-45bd-84f3-08d7f384f702 x-ms-traffictypediagnostic: DM6PR05MB5161: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 039735BC4E x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6Fr6TZIkwMKk0mlHPSKJrYipJ0QXmeVLBsCbx8xBbt/12h3FUw0Cw1TzZSdD59joov9E6WBoHt9q9uvAsbw0MvxJO/9n1b7mMapW5EnKBhTQmKGKt8fl+7careZntVeb0np6fcF3Yk35OFxFTavpMm0jPBgk2Zj6wWbnCoqiimvECCmh1vztNR0HAtiqJy85TkZpYCb5kESNzVGiNS5VeaAZdtxOLtwUEB/MZraVts0Dme7koiqB8VjVqtL0Ot72MeWspjnN4hwQdCM8N0AVsV6CnvFUGulivDYxm0Zg/77y055gnAvixdkMSCCYf1DQHmoGz6iY3yts7VKPpPVWQ0AIhf7YvbKRjOyE17ZxWYR9fNwcE7jEWYi33v8eYXkww/UKpbsVkjPk8Lzo+ZR3AfujrJpiM4NRV6bzpSITypsbCn4TPqT6DpXssqG2CW6ITRihYGFuGhUQ11w5S/G2r5X3+hzdZ8TAmTzKU7rmznULLCgvL3IihwIp4genD5qPIqacnmHkT/ouaS7rb1o29caEWDtJkSTy3LtQh+AZRMuJbg4U0dbl1XbfeVQSGrppbmceLKD7MoCmc8E34nJqlfqcvA9vamuEYbNHenloxuQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(136003)(346002)(366004)(376002)(33430700001)(71200400001)(15650500001)(966005)(478600001)(33656002)(66476007)(76116006)(52536014)(186003)(26005)(66446008)(83280400001)(83320400001)(83310400001)(55016002)(66556008)(83290400001)(8676002)(8936002)(64756008)(83300400001)(4743002)(9686003)(5660300002)(33440700001)(86362001)(6506007)(7696005)(66574014)(66946007)(2906002)(316002)(110136005)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: YrotL+1mrMDl8PxKEOpK/CSp0w4DdHJbzagzR/kktGhI7TFugoxNEsoPuvT8S6TnpDp7NiNQ/hqN2RtkpG09pFnqCDeX+oIkIZQ+NmxQsfA0pXMQhqciHZQ9XEmn/fkQaP4HX2dL1kAjug2TMKrbqTSf2V55oQaXrIZHwpxuG9O1yGAdOMRI8txTJIKy+11c0jf6a6BvgTlXCciGIvTRo3YCOfGDKFt70q6eRUSv6lo2GuDDL+G3GUMWkeBtB5wYLVjLBN1MS+K0Kl1/u3Yl8Rinlx3EK80mRVs7jexEPbPHJjhEudsFt0WioWO7UeW0mIltyInZd//6kS2ObZW8kkeJ2AFoFGOSIpBGwdYYlxq2oFwqcB9fjp6OsxZ2cbnYwO86lx7Yzb3nR3F9+R+QzQPYtzxTmlYTddK0WZUPOKh0XA0ZijeJCdnCtCxkULOKjoeh/d+wbiIpRQKS2aMzt4YNuCQWjPA7F0hvcC+FgWvYXqBmGheb5MNVZB10BRyX x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: c22a47b5-9187-45bd-84f3-08d7f384f702 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 19:21:10.0295 (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: 9oxXQZqBOO0/zLfmpjzynU1tKqAmF60JlsM4QNmz/Fgh2667czBi133+8XFg0omtkHDIgtGp8ZlSjo4YGtdt8w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5161 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-08_16:2020-05-08, 2020-05-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 bulkscore=0 spamscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 suspectscore=0 priorityscore=1501 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005080163 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 19:21:27 -0000 Folks, The paragraphs in question state a rule in the negative. They tell us that = transit node (i.e., nodes that are neither segment endpoints nor the packet= 's ultimate destination) must not insert, process or delete extension heade= rs other than the HBH. This leaves the reader to infer what the rule would be if it were state in = the positive. Possible inferences are: - Segment endpoints and the packet's ultimate destination node can do what= ever they want - Some set of unstated rules govern the behavior of segment endpoints and = the packet's ultimate destination Two reasonable individuals might argue about which interpretation is most a= ppropriate. They might even find a compromise position. The purpose of this draft is to facilitate (if not force) that conversation= . Regardless of which conclusion we reach, we need to document it.=20 Flexible standards are a good thing. A good standard allows appropriate deg= rees of freedom and describes them clearly. Ambiguous standards are a bad thing. They lead to unproductive and irresolv= able debates. Gyan is correct when he observes that our attention would not have been dra= wn to this paragraph had it not been for SPRING. But we need to disassociat= e this discussion from SPRING and our passions about it. Let's worry about = IPv6 in this WG. Once we reach a conclusion, we can figure out what allowan= ces need to be made for SPRING. Ron Juniper Business Use Only -----Original Message----- From: ipv6 On Behalf Of Philip Homburg Sent: Friday, May 8, 2020 2:04 PM To: ipv6@ietf.org Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-= 03=20 [External Email. Be cautious of content] > What I am struggling with is what can we possibly hope to achieve by=20 > publishing this draft... It seems to me that the interpretation of RFC 8200 that an intermediate rou= ter in the context of a routing header may arbitrarily insert, delete, or m= odify any extension headers, makes routing headers a very dangerous concept= . To the extent that this is obviously wrong, it make sense to adopt Fernado'= s erratum (https://urldefense.com/v3/__https://www.rfc-editor.org/errata/ei= d6003__;!!NEt6yMaO-gk!Uui_6Edvm9V1eIojAqFcloT_bUU0-WA8ooY9S_dZ4jTn0S8o6cO98= 3hUc2nqIloz$ ). However, it can be said that this particular case was never discussed befor= e RFC 8200 was published. In that case the erratum can be rejected, and we = can see if this draft reaches (rough) consensus. Independent of merrits of segment routing, allowing arbitrary inserts, dele= tes, or modifications is not a good thing. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/m= ailman/listinfo/ipv6__;!!NEt6yMaO-gk!Uui_6Edvm9V1eIojAqFcloT_bUU0-WA8ooY9S_= dZ4jTn0S8o6cO983hUc8QvMqb7$ -------------------------------------------------------------------- From nobody Fri May 8 12:26:17 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9243A0DFD for ; Fri, 8 May 2020 12:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWlzaWuflJ8Z for ; Fri, 8 May 2020 12:26:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E446A3A0DF9 for ; Fri, 8 May 2020 12:26:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jX8dO-0000JrC; Fri, 8 May 2020 21:26:10 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: In-reply-to: Your message of "Fri, 8 May 2020 15:13:26 -0400 ." Date: Fri, 08 May 2020 21:26:10 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 19:26:15 -0000 > However, if you look at it after PSP node has received and > processed the PSP function psuedocode you are now in RFC 8200 > conformance. If you say only the final destination of the IPv6 packet removes the extension headers and no intermediate router inserts or removes anything, then there is no conflict with draft-bonica-6man-ext-hdr-update-03 or with Fernado's erratum. So we just accept either of those as a clarification of RFC 8200 and move on. From nobody Fri May 8 13:33:31 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDEE3A0EBC for ; Fri, 8 May 2020 13:33:22 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 ljGMgST8gqt0 for ; Fri, 8 May 2020 13:33:20 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 B2EAA3A0EE2 for <6man@ietf.org>; Fri, 8 May 2020 13:33:19 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id x7so8662481oic.3 for <6man@ietf.org>; Fri, 08 May 2020 13:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lnasNMxF1Lnxm12AcEahJ6WtNlSMJhv60RKgK5DRazM=; b=F66pvHAryA3DNlVgoeWOJgmIo29YL2oDgjcHhgNB1YFHJ5bOpLLdg5LoU0IeXXzhzb HMdzfg/ZYjn4naPlmnuxgpUl1p4N4bdwWei1kbaGdX5dJY/+no/u4qETPn90673ihJyg F17Hl9lmTNqZ3UoDNvGshqc1wn8zX5YbZMEAcKqn01zZLfOZMnTk/2SEwVUcL2N4SgBN pRfCP5tAAW6tBpPCjRiTcy/D5IfeskE3tEhqyqstxVUKHRvMMQErNIxUDhtVSg8y4QE+ pKGpvqE9+CC29Jb5IiwW/doxy5bTJ4hJQUChKWCeITCG+UzNN0zrHbbHL9eL+umHSPQT m4LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lnasNMxF1Lnxm12AcEahJ6WtNlSMJhv60RKgK5DRazM=; b=X4YMsL3vzkFPOlwVgPlVpIHicIvFKYqKrMuCxL6VxzufxLHKFZGxVQuQKxzT6fv/QR LyhkaIRBOxmSL7LhWkGcNitu/bY5IgNmDZhVL4g26c5sdK0BOko+LLIWQdzDLNkrKKeS 2Y8aTdhvSVL0xB/ZNkBz5qNeGoeD1+C6m0kE6W7SqNrrRdnwzKNfnUqKa6JRGBN07BQL YxSnDghwa8EeE8zBNFJ4w2umWXntvhRRvoCeQhNmkugcGCDyzdQ7ZWC18aRXMNIH8m8S nZ/S3eJCWuD5rTTMRkNWDlC8OICTIivFS3PY0JhB94/nRcGBrS2mVmSp2bpNeLeiy5MO 04+w== X-Gm-Message-State: AGi0PuYDKUt3URsk5gzYEfZYqmUk97kT2fhkuxkzIcnXXkVtOuSGkWY6 Spkccxdfx3ugDiuMGHqTrmLyylyXt5I1wJYJS1c= X-Google-Smtp-Source: APiQypJzutejZ4BZgPEy5dBR9sBgZ5n0vI4li8z0ThJDj7aJTIZBt9K06JolQ3PtitjqzprrdJ7mDDzNDZ9fdUq/OcA= X-Received: by 2002:aca:cf83:: with SMTP id f125mr11997380oig.97.1588969998845; Fri, 08 May 2020 13:33:18 -0700 (PDT) MIME-Version: 1.0 References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> In-Reply-To: From: Erik Kline Date: Fri, 8 May 2020 13:33:08 -0700 Message-ID: Subject: Re: Routing Header Insertion To: Tony Przygienda Cc: "Joel M. Halpern" , 6man <6man@ietf.org>, "Darren Dukes (ddukes)" Content-Type: multipart/alternative; boundary="00000000000057195305a528e8c7" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 20:33:23 -0000 --00000000000057195305a528e8c7 Content-Type: text/plain; charset="UTF-8" (Sometimes it's a bit hard to keep up with some of the faster-moving threads, especially when the day job demands more focus.) [ picking a random message in the stream to reply-all ] I agree that we should conclude this particular thread. Please, let us all take a breather and try to reset. I wish everyone a pleasant, restorative weekend. I also apologise it took me this long to catch up. -ek --00000000000057195305a528e8c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Sometimes it's a bit hard to keep up= with some of the faster-moving threads, especially when the day job demand= s more focus.)

[ picking a random message in the s= tream to reply-all ]

I agree that we should conclu= de this particular thread.

Please, let us all take= a breather and try to reset.=C2=A0 I wish everyone a pleasant, restorative= weekend.

I also apologise it took me this long to= catch up.
-ek
--00000000000057195305a528e8c7-- From nobody Fri May 8 14:22:33 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB8A3A0F37 for ; Fri, 8 May 2020 14:22:11 -0700 (PDT) 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, 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=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwOJowKlaS1o for ; Fri, 8 May 2020 14:22:08 -0700 (PDT) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 AEB753A0F34 for ; Fri, 8 May 2020 14:22:07 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id nv1so2477238ejb.0 for ; Fri, 08 May 2020 14:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1e7vGVusuILjmMNwtRMz8yWdpWviIjr4Oqd6FZj2pkU=; b=KYXy8p3IJg5IIrQ6NOzctgUgFOc4mIKlYNgbPYta/vO1yzIznBEIJqYz3W+gqpeWJr YRyfum3brFB8WvgSLrY0qLN8ZTrBXKI/loFq6HLbrapQdOLRgii0qj0/YYP5AaALXiy2 ObSPxMD8TCoVCwnMNS++xGwq059ttFHo52eHpJhhZwXVP/Wy9wbOlVEG04Q8GxM728I1 2gOTZlF6fxWTRNWzLm9hjeufHpjnQCpPAKxSqRzFS6RrcRnd9qkfbqVkN8AHGS/Tan+m Fsl+ipttT+QIxjxyFZLQaXvu/wRXGr2YY6kCj0voy2HYZ7ixlT3mxwHzO33KqeyOUstK dDXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1e7vGVusuILjmMNwtRMz8yWdpWviIjr4Oqd6FZj2pkU=; b=odBtjBbSNCom0h+lPZ/KVAlgx/75Oh/rRaft2oRQIyV9wpxYgIyP7EuaPWx7EIz/RN n1n8vlswoazLXQtrxeYmCzyAGt9gzwzUMQbhAiyoafmU+jtit67l2uhOZS5MJtM2pIcr gF+4bS9iD+yjRhOC6fLenmEE10qmZNR2tPU7x24iQP7x2QbdidUGim2csbh4jjJMvK9F SY6IdBQhegzo4FMmAPUN2m5n1SUDSmOH/9/acqJti9LiVwxwogrPecIAbkBsXiioapCR UrRSOqXF+C0SEGIpMaHTYWlFrIVNqZVp/F1Ex3XXRbryfb+GnnyP0bMxg4zx1M0HvE+E vRmg== X-Gm-Message-State: AGi0PuaDrcrt0KRKSDh13oXn54D7pRpnZAdXpzTndWjoFyxlpHWcqk3j bdUK82MEEdrRKR8xt6Y4bssjp+b1TIjlGvsHpujwhQFd X-Google-Smtp-Source: APiQypKTiuFW5d08MpuDxYVbG+Y/EkSX/bt21PLyRI9kWgly+WlaHHtTA5vJFir5qpQ/wvAoOpEPHXjeLR4vDf6fFq8= X-Received: by 2002:a17:906:1fd6:: with SMTP id e22mr3801245ejt.150.1588972925448; Fri, 08 May 2020 14:22:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Fri, 8 May 2020 23:21:56 +0200 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Philip Homburg Cc: 6man WG Content-Type: multipart/alternative; boundary="000000000000c78ab605a52996f7" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 21:22:12 -0000 --000000000000c78ab605a52996f7 Content-Type: text/plain; charset="UTF-8" Hello Philip, I am not sure if you have carefully followed 100s of emails so far on either 6man or spring WG lists. Your comments lead me to believe that perhaps you missed the key point here. Lecture of the subject draft also does not help at all to clarify what the behaviour should be as it just does not talk about the problem at hand. It talks about something which IMHO is obvious to all of us. It mixes end to end required behaviour with transport behaviour - completely different layers of transport all within layer 3. So let me for clarity restate the problem - hoping that those who do care about technical points will find it useful: Application opens a socket and original IPv6 packets get's send from node N1 to final/ultimate/etc destination N2. Obviously it contains some v6 base header and may contain some extension headers. No one here is doing *anything* to this very headers. For those calling it end to end principle of IPv6 no one is changing a bit. Those stay intact. But as it is unfortunately the case N1 and N2 may not be directly connected. Worse to get from N1 to N2 packets may need to transit via third party network or networks. So it is very common that each transit network today implements some form of encapsulation for various reasons. Some use IPv4 encap, some use MPLS-LDP, some use RSVP-TE, some use IPv6 in IPv6. Even if you go and try to buy "a circuit" you will be getting an emulated circuit over someone's IPv4 or IPv6 network. Transport network operator is responsible for his network - so all claims that oh if I insert a bit here or there packets may exceed MTU and will be dropped while theoretically true really do not happen in real life as no one sane accepts the larger packet which it would not be able to carry as transit provider. Besides if someone would he would be out of business already so nothing for IETF to worry about. So now comes the crux of what some call "the issue". On the edge of transit network T1 packets is getting a new IPv6 header. Original packet intact is wrapped and placed into the new envelope. Sometimes DST of the packet T2 means egress from transit network. Sometimes it means a middle hop which by network programming will know how to handle it and apply new destination Tn. I do not see anything wrong with any "intermediate destination of the packet" to do what it considers best in order to deliver packet to the transit network egress node. Now comes the topic of an additional hander mangling even by nodes which are not intermediate destinations, yet all within transit network. Real use case example of this would be the local path or node protection. The less overhead it incurs the better for the end to end service hence those arguing let's apply new IPv6 header there are just off in the efficiency curve - even if it perhaps simplifies some of the hardware processing. If we can insert arbitrary MPLS stack anywhere in transit why one would not be able to insert a new SRH into his own IPv6 transit header ? SIDs are much larger - oh no ... take a look at our vSID proposal. Finally packet gets to the ultimate egress of transit network and continues its journey towards N2. To conclude - all what transit does with the packet has nothing to do with end to end principle. If someone is trying to fit today's networking into OSI model I am afraid it will fail as OSI model does not map today's flavors of IP layer 3 transport planes. If some would like to see N1 to N2 traversing without any encapsulation I believe need to build new Internet by themselves starting with dark fiber. Mean time folks trying to use IPv6 to deliver better services are facing some fascinating oppositions which can not even in technical terms explain the issue. I am really puzzled what the subject draft is trying to clarify. Plain mortal reading does not reveal the mystery behind it. Maybe printing it on good printer and flashing UV light would help ? Maybe some have special decoder which would reveal the real text. No idea. Kind regards, Robert. PS. Another way to look at this space is to either accept that encapsulation of IPv6 in IPv6 is allowed or not. And as we are rewriting L2 header at each L3 hop - one can consider SRv6 technology as rewriting IPv6 header at each L3 hop within a given network. If so all header operations are permitted by each hop if not by RFC8200 then by RFC2473. On Fri, May 8, 2020 at 9:26 PM Philip Homburg < pch-ipv6-ietf-6@u-1.phicoh.com> wrote: > > However, if you look at it after PSP node has received and > > processed the PSP function psuedocode you are now in RFC 8200 > > conformance. > > If you say only the final destination of the IPv6 packet removes the > extension headers and no intermediate router inserts or removes anything, > then there is no conflict with draft-bonica-6man-ext-hdr-update-03 or > with Fernado's erratum. So we just accept either of those as a > clarification of RFC 8200 and move on. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000c78ab605a52996f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Philip,

I am not sure if you have= carefully followed 100s of emails so far on either 6man or spring WG lists= .=C2=A0

Your comments lead me to believe that perh= aps you missed the key point here. Lecture of the subject draft also does n= ot help at all to clarify what the behaviour should be as=C2=A0it just=C2= =A0does not talk about the problem at hand. It talks about something which = IMHO is obvious to all of us. It mixes end to end required behaviour with t= ransport behaviour - completely different layers of transport all within la= yer 3.

So let me for clarity restate the problem -= hoping that those who do care about technical points will find it useful:= =C2=A0

Application opens a socket and original IPv= 6 packets get's send from node N1 to final/ultimate/etc destination N2.= =C2=A0

Obviously it contains=C2=A0some v6 base hea= der and may contain some extension headers.=C2=A0

= No one here is doing *anything* to this very headers. For those calling it = end to end principle of IPv6 no one is changing a bit. Those stay intact.

But as it is unfortunately the case N1 and N2 may n= ot be directly connected. Worse to get from N1 to N2 packets may need to tr= ansit via third party network or networks.=C2=A0

S= o it is very common that each transit network today implements some form of= encapsulation for various reasons. Some use IPv4 encap, some use MPLS-LDP,= some use RSVP-TE, some use IPv6 in IPv6. Even if you go and try to buy &qu= ot;a circuit" you will be getting an emulated circuit over someone'= ;s IPv4 or IPv6 network.=C2=A0

Transport network o= perator is responsible for his network - so all claims that oh if I insert = a bit here or there packets may exceed MTU and will be dropped while theore= tically true really do not happen in real life as no one sane accepts the l= arger packet which it would not be able to carry as transit provider. Besid= es if someone would he would be out of business already so nothing for IETF= to worry about.=C2=A0

So now comes the crux of wh= at some call "the issue". On the edge of transit network T1 packe= ts is getting a new IPv6 header. Original packet intact is wrapped and plac= ed into the new envelope.=C2=A0

Sometimes DST of t= he packet T2 means egress from transit network. Sometimes it means a middle= hop which by network programming will know how to handle it and apply new = destination Tn.=C2=A0

I do not see anything wrong = with any=C2=A0 "intermediate destination of the packet" to do wha= t it considers best in order to deliver packet to the transit network egres= s node.=C2=A0

Now comes the topic of an additional= hander mangling even by nodes which are not intermediate destinations, yet= all within transit network. Real use case example of this would be the loc= al path or node protection. The less overhead it incurs the better for the = end to end service hence those arguing let's apply new IPv6 header ther= e are just off in the efficiency curve - even if it perhaps simplifies some= of the hardware processing. If we can insert arbitrary MPLS stack anywhere= in transit why one would not be able to insert a new SRH into his own IPv6= transit header ? SIDs are much larger - oh no ... take a look at our vSID = proposal.=C2=A0

Finally packet gets to the ultimat= e egress of transit network and continues its journey towards N2.=C2=A0

To conclude - all what transit does with the packet h= as nothing to do with end to end principle. If someone is trying to fit tod= ay's networking into OSI model I am afraid it will fail as OSI model do= es not map today's flavors of IP layer 3 transport planes.
If some would like to see N1 to N2 traversing without any enca= psulation I believe need to build new Internet by themselves starting with = dark fiber. Mean time folks trying to use IPv6 to deliver better services a= re facing some fascinating oppositions which can not even in technical term= s explain the issue.=C2=A0

I am really puzzled wha= t the subject draft is trying to clarify. Plain mortal reading does not rev= eal the mystery behind it. Maybe printing it on good printer and flashing U= V light would help ? Maybe some have special decoder which would reveal the= real text. No idea.=C2=A0

Kind regards,
=
Robert.=C2=A0

PS. Another way to look at this= space is to either accept that encapsulation=C2=A0of IPv6 in IPv6 is allow= ed or not. And as we are rewriting L2 header at each L3 hop - one can consi= der SRv6 technology as rewriting IPv6 header at each L3 hop within a given = network. If so all header operations are permitted by each hop if not by RF= C8200 then by RFC2473.


On Fri, May 8, 2020 at 9:26 PM P= hilip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> wrote:
>=C2=A0 =C2=A0 However,=C2=A0 = if you look at it after PSP node has received and
>=C2=A0 =C2=A0 processed the PSP function psuedocode you are now in RFC = 8200
>=C2=A0 =C2=A0 conformance.=C2=A0

If you say only the final destination of the IPv6 packet removes the
extension headers and no intermediate router inserts or removes anything, then there is no conflict with draft-bonica-6man-ext-hdr-update-03 or
with Fernado's erratum. So we just accept either of those as a
clarification of RFC 8200 and move on.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--000000000000c78ab605a52996f7-- From nobody Fri May 8 15:04:46 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF753A0F41 for ; Fri, 8 May 2020 15:04:39 -0700 (PDT) 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, FREEMAIL_FROM=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 qh5M0IgbbszB for ; Fri, 8 May 2020 15:04:36 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 69C373A0FA1 for ; Fri, 8 May 2020 15:04:36 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id a7so4896265pju.2 for ; Fri, 08 May 2020 15:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Tse9Sz95HiGpxECnx0Mk6gDvDlubxdUdyWHmJeul0+A=; b=dp4IQ0dA5k+JicjB82zdngUimQMWpn6vCgEjtcQhg112vBkyF+aO7RQZAEp+rNGhRP jc3jFYMwQzYFRgb10DbM+3fYPrbf8cj0TtV0UyHq755+IXtDccYw+8fmeh1ituArmLPr mW4BbpDTfPHHGnBh6mqy4itmS/D2bUbU1oBGeZdQNCz7XkmbhYoLUAzqKzFxxLcWA4zy y+AflHa4Kx9yqy379ThGQ/+yCyV7cRl+mtEsouQezfg7z3iiNVOFvdmRv5S3g/M1T+Rr 7GuoTZqyq3b72WiLx7wIM5TxzHgdjECh1VDNpUB2Q7bzXTO6oiBj0Ivrrrv/V+X0dmAX atYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Tse9Sz95HiGpxECnx0Mk6gDvDlubxdUdyWHmJeul0+A=; b=Je13pBbSYLd7hfVTLf1mYOTeUBHe1dHY3XbZvdDROca7bg3SNl5rphXMvTsoWq/qk0 gSqPFo70msAiCC4IzAfZtvaKTIUIj/VqQ0862K8bs+0E2tLia1ZWw5A7AmO0tBwQRYad 9rjfCeFb1yr+0+yq0KzZ1ZKAuhrb2/W5hsBTl2k9cFnHtYUlhZLiSAQ+55P/cfzfYzoI rbY2/xnRsM4WgMBzVsMhasof+4CsxajFOR6Ro0Pq2EjpzznhPReGa/ww5RgmqPTx0ggX KU4OjJ9DAwPUtd2vUDZUXYZnB+Qr8qrADMT71JhvhGLzQncGaPHj/Qq0it93oSWSa/Vi ojWQ== X-Gm-Message-State: AGi0PuaeEgUtm1GItlkky8hWXmCSUK8GteEBAtLn72ZVbvBbuVHk+YMz Adr1Bq1Dq7GtaC/fIpEViBOXXsQY X-Google-Smtp-Source: APiQypLPHYmMDYB2Y7+RnQj3CDo5M+seFac7ldl2zcv1kKC7oghTD7pjuQNRXkIq0J25iLofUG/u6g== X-Received: by 2002:a17:902:7048:: with SMTP id h8mr4418372plt.300.1588975475390; Fri, 08 May 2020 15:04:35 -0700 (PDT) Received: from [192.168.178.30] (207.252.69.111.dynamic.snap.net.nz. [111.69.252.207]) by smtp.gmail.com with ESMTPSA id y21sm2669774pfn.148.2020.05.08.15.04.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 May 2020 15:04:34 -0700 (PDT) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Gyan Mishra , Philip Homburg Cc: ipv6@ietf.org References: From: Brian E Carpenter Message-ID: <6d6478a9-967c-7104-4725-58027884f6ae@gmail.com> Date: Sat, 9 May 2020 10:04:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 22:04:40 -0000 Gyan, On 09-May-20 07:13, Gyan Mishra wrote: > I was digging through the many threads with Spring and here is excerpt = from my reply to Darren Dukes and Jingrong which states exact area where = the issue arises with EH removal with PSP and the area of confusion.=C2=A0= I wonder maybe we can add this example in a stick diagram in the update = so it=E2=80=99s crystal clear. >=20 > Excerpt below: >=20 >> The key is that to the PSP node the incoming SL is 1 - but after the f= inal DA is copied the SL pointer is updated so the outgoing SL is 0 - t= his satisfying the pseudocode criteria and RFC 8200 to remove the SRH sin= ce the final DA is now set. =20 >>=20 The problem with that is that standards for protocol data units are about= what goes on the link, not about what happens inside a node. PSP is appl= ied to a PDU with SL>0 and that is allowed by RFC8200 only if you interpr= et "destination address" as the current destination address rather than t= he ultimate destination address. The draft removes that ambiguity in RFC8= 200 (and in answer to Ole, the draft is necessary precisely because RFC82= 00 is ambiguous, which is also why this cannot be fixed by an erratum). In other words, +1 to Philp Homburg's message. Brian >=20 > If you look at this before the packet is received then it appears as in= flight and not final destination so it may appear not in RFC 8200 confor= mance which has been the contention all along.=C2=A0 However, =C2=A0if yo= u look at it after PSP node has received and processed the PSP function p= suedocode you are now in RFC 8200 conformance. >=20 > Kind=C2=A0regards >=20 > Gyan >=20 > On Fri, May 8, 2020 at 2:04 PM Philip Homburg > wrote: >=20 > > What I am struggling with is what can we possibly hope to achieve= > > by publishing this draft... >=20 > It seems to me that the interpretation of RFC 8200 that an intermed= iate > router in the context of a routing header may arbitrarily insert, d= elete, or > modify any extension headers, makes routing headers a very dangerou= s concept. >=20 > To the extent that this is obviously wrong, it make sense to adopt = Fernado's > erratum (https://www.rfc-editor.org/errata/eid6003). >=20 > However, it can be said that this particular case was never discuss= ed before > RFC 8200 was published. In that case the erratum can be rejected, a= nd we > can see if this draft reaches (rough) consensus. >=20 > Independent of merrits of segment routing, allowing arbitrary inser= ts, deletes, > or modifications is not a good thing. >=20 > -------------------------------------------------------------------= - > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6= > -------------------------------------------------------------------= - >=20 > --=20 >=20 > Gyan=C2=A0 Mishra >=20 > Network Engineering & Technology=C2=A0 >=20 > Verizon=C2=A0 >=20 > Silver Spring, MD 20904 >=20 > Phone: 301 502-1347 >=20 > Email: gyan.s.mishra@verizon.com >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Fri May 8 15:42:04 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD023A1073 for ; Fri, 8 May 2020 15:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0_vSEDqRH0G for ; Fri, 8 May 2020 15:42:01 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7A53A1071 for ; Fri, 8 May 2020 15:41:59 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jXBgr-0000KxC; Sat, 9 May 2020 00:41:57 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: In-reply-to: Your message of "Fri, 8 May 2020 23:21:56 +0200 ." Date: Sat, 09 May 2020 00:41:56 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 22:42:03 -0000 >Now comes the topic of an additional hander mangling even by nodes which >are not intermediate destinations, yet all within transit network. So this is the key point. RFC 8200 applies to all IPv6 packets. So if RFC 8200 allows additional header mangling, then that can happen in lots of other places as well, which is quite undesirable. So RFC 8200 has to state that in general this sort of thing cannot happen. Next we can update RFC 8200 with a narrowly crafted exception tailored to this use case. We have two possibilities: - either RFC 8200 allows mangling by hops in a routing header. In that case we have a problem that needs to be fixed while creating an exception for segment routing, or - RFC 8200 does not allow this kind of mangling and we need to create an exception for segment routing. From nobody Fri May 8 16:06:36 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D02C3A104A for ; Fri, 8 May 2020 16:06:33 -0700 (PDT) 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, 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=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR9XSufQP9LI for ; Fri, 8 May 2020 16:06:31 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D28D3A1053 for ; Fri, 8 May 2020 16:06:31 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id h15so359401edv.2 for ; Fri, 08 May 2020 16:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PzAxde2AN8/OZLFxL19bak6tnxhfBYqHiERPgXpqLKA=; b=YXZ366CTQ21KsDpB/3YtucIW9c3rhX86uBS0KEF6G0PR4RRL7grEzGLWgYb5YzuX7M 1uJ+S/yaAIs2r4M6PkwI42PV2QhBOWOAaPTeez+VxWAaEyn1SG3ZQKhnZjUqznnic6+A dBFt+0TutZbskZH1qy4Zy84vt2y8j/rlIaUuuZynn/oAj/uw27K9oSxKZaoJnDC7Nq/b Z8J1RA5EHLaj0irOgnQS7pE39yc25neDydRV1Zw1Ohsjx8fayGdzGjEzo6Yo3uDFtVA+ U3S+VtV2FXHwLONKFuaBgPnh1YZUidgQyxwOSdRklucDYKsMLAsZzDh1sQ1VVJYZsD7e s6aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PzAxde2AN8/OZLFxL19bak6tnxhfBYqHiERPgXpqLKA=; b=Y5GSEoUz2OTaGVxQHB//O4+cwqvSap9Xqi16EZajd9ONQLQXUYB5+2oaifg5lW0IqK AeRV8lwLgdFcZ1jMxDnqazKbwxAWHoHpHa7d5ViJ/W/oZE7n4PurEkYYFsZkOlgyvZlP HsYR+tMd0YzmgQXaPkX/FTGhEchEGEy1TnXUL4Fal2brQhayWRcxytZwz9toEe2sSoQW +Rr8JA+2SgqRBtitP9DtOeQVUXv0bJl5SnyIruKz5t7aE+nxXI6Eex8j+lWFOKqI8rdf fTKMEeOhP6MHiwBPkzS6Lamn+W/jTd9jMXF5EpXo/zDbpR0VUFAyS8jikh37xH3AHYCs wexw== X-Gm-Message-State: AGi0PuaYc7nYpm/iGLLhXxpluip1kNAOwkIEEZSn8YPWN+T/r87HAjAX zXEOlJ3Gtly8PX/vmifCyWl/N/Q4dbb1/arFyzs4NanJ X-Google-Smtp-Source: APiQypJaH+XpusvjjSt0prxsXaqRtvj9pdO3Qlyw87Kpk/wYzKXSAusKmw10PItl9pQMbomEMr0+/ZOL5xzXUH1FuUw= X-Received: by 2002:aa7:c1cf:: with SMTP id d15mr4064146edp.266.1588979189713; Fri, 08 May 2020 16:06:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Sat, 9 May 2020 01:06:20 +0200 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Philip Homburg Cc: 6man WG Content-Type: multipart/alternative; boundary="00000000000028aa2105a52b0c41" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:06:33 -0000 --00000000000028aa2105a52b0c41 Content-Type: text/plain; charset="UTF-8" Hi Philip, Sounds very reasonable. IMO what is needed here is a short spec which would explicitly call out the case of using IPv6 as transport layer. Then it would allow the transport owner sufficient flexibility (insertion, modification, deletion) into applied by his own ingress new IPv6 header at any transit hop he seems required. Ultimate goal is to deliver carried payload (here original IPv6 or IPv4 packets) via a given network the best quality possible. Thx a lot, Robert. On Sat, May 9, 2020 at 12:42 AM Philip Homburg < pch-ipv6-ietf-6@u-1.phicoh.com> wrote: > >Now comes the topic of an additional hander mangling even by nodes which > >are not intermediate destinations, yet all within transit network. > > So this is the key point. RFC 8200 applies to all IPv6 packets. So if > RFC 8200 allows additional header mangling, then that can happen in lots > of > other places as well, which is quite undesirable. > > So RFC 8200 has to state that in general this sort of thing cannot happen. > Next we can update RFC 8200 with a narrowly crafted exception tailored to > this use case. > > We have two possibilities: > - either RFC 8200 allows mangling by hops in a routing header. In that > case we have a problem that needs to be fixed while creating an exception > for segment routing, or > - RFC 8200 does not allow this kind of mangling and we need to create an > exception for segment routing. > > > --00000000000028aa2105a52b0c41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Philip,

Sounds very reasonable.=C2= =A0

IMO what is needed here is a short spec which = would explicitly call out the case of using IPv6 as transport layer. Then i= t would allow the transport owner sufficient flexibility (insertion, modifi= cation, deletion) into applied by his own ingress new IPv6 header at any tr= ansit hop he seems required. Ultimate goal is to deliver carried payload (h= ere original IPv6 or IPv4 packets) via a given network the best quality pos= sible.=C2=A0

Thx a lot,
Robert.

<= /div>

On Sat, May 9, 2020 at 12:42 AM Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> wrote= :
>Now comes = the topic of an additional hander mangling even by nodes which
>are not intermediate destinations, yet all within transit network.

So this is the key point. RFC 8200 applies to all IPv6 packets. So if
RFC 8200 allows additional header mangling, then that can happen in lots of=
other places as well, which is quite undesirable.

So RFC 8200 has to state that in general this sort of thing cannot happen.<= br> Next we can update RFC 8200 with a narrowly crafted exception tailored to this use case.

We have two possibilities:
- either RFC 8200 allows mangling by hops in a routing header. In that
=C2=A0 case we have a problem that needs to be fixed while creating an exce= ption
=C2=A0 for segment routing, or
- RFC 8200 does not allow this kind of mangling and we need to create an =C2=A0 exception for segment routing.


--00000000000028aa2105a52b0c41-- From nobody Fri May 8 16:28:10 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7345F3A100C for ; Fri, 8 May 2020 16:28:08 -0700 (PDT) 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 XA1c7gWJYGZo for ; Fri, 8 May 2020 16:28:06 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 DC2133A0E40 for ; Fri, 8 May 2020 16:28:05 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id f3so3523280ioj.1 for ; Fri, 08 May 2020 16:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gTtytDcrPU6sYBMIu6JocwLEuwoz7f7m2hR37Olt7bk=; b=VnQbImiQZ9Y3P62FBgb+vLBowUkOzXwJwoqtATdzkykZOvId36spBSbZvRRNtXjilv pg18L7RN9nZMj+k0ZpU0zL9SDhW/cicYSdfKOzetHJGcsqGZNK8hRmoWPq9aDBveo17A QECijadZFt3qofviVMVhU2zMrKauU/z6sPySuxizwlRObct3ibFV/UrqYGOhwtMRDAQi ZouIFuKEBvuPgv9gzZPTxzsI9AlaMX2oMAyWumy8oMAf/yKnplhuN3b6H0P/52JtGW9+ j9JRD5cx88FhiUFY9oys3Emc7hAI/SNlsjJttAiCbcQ0OPkfu5NwJcODXuB99hkWCs7d scdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gTtytDcrPU6sYBMIu6JocwLEuwoz7f7m2hR37Olt7bk=; b=Vq9H0mLMumXmAeUCUxB63XgfFjo+QRnTfcOXadSZAv4dFyJNM9Dh7QKRkiNNdZTiSV ok+dB0u12OZbAXqrz/zyRGNenF90Lb559afo/7N36K9bRikW0IgwxxM1E8urux56XAVM bASF3TQjdHEJE7TQu8vFRjuS482mu/Pkiht5iWpjONK7p3yziU5/6Ol565n1Qz/RNsoq mQiYz5HiLBhnu1XBnCYISdcpkyNA9vK6DhA0PB1fTtOmVvZlub1rQymk1mn0nznaUPND HJ9QKkGvuj6pBthmo0aEz5CDeY59+gOSzYvMNUQm7iCqyk/qvDUMuzn1NMtcZhIioaom MzLQ== X-Gm-Message-State: AGi0PuYYFe00sRBhOERrTnESbXSD7WjVs0w/QPYrNQTeUr+khbc3BB+h 71HjGHVvLPcMtb9hNfaOwLnO4Va8ugdJv2zwJRdRXjNwobU= X-Google-Smtp-Source: APiQypLx+gkx63cuw5+khaQte0KhDVmflDGQW84/8ipOJ1cDcUgaWWLCLtvVb55eCNQ/29wr1aRXUCRC4WwqjDxbbKU= X-Received: by 2002:a02:9a0d:: with SMTP id b13mr4952654jal.60.1588980484796; Fri, 08 May 2020 16:28:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Fri, 8 May 2020 19:27:53 -0400 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Robert Raszuk Cc: 6man WG , Philip Homburg Content-Type: multipart/alternative; boundary="00000000000059f53805a52b59b1" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:28:09 -0000 --00000000000059f53805a52b59b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Given that SRv6 PGM draft has left the station awaiting publication I think the most prudent recourse for 6MAN is to grant the exception for SRV6 technology to allow insertion and removal on any transit node within the carriers administrative domain. https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming= / DocumentType Active Internet-Draft (spring WG ) Last updated 2020-04-14 (latest revision 2020-03-27) Replaces draft-filsfils-spring-srv6-network-programming Stream IETF Intended RFC status Proposed Standard Formats plain text xml pdf htmlized (tools) htmlized bibtex StreamWG state Submitt= ed to IESG for Publication Document shepherd Bruno Decraene In the verbiage as to reasons why this being allowed is that SRv6 would always be used in a closed domain with standard security protection mechanisms at ingress and egress of the domain. Domain definition would have to be defined as a carriers administratrative domain where the carriers transport network could span multiple ASs that are inter connected via SR-TE bsid or inter-as L3 vpn. One caveat loophole does exist is that inter administrative domain intent based SR flows would also be allowed so in theory you could have a chain of SRV6 domains over the internet or even private inter connected domains so then maybe not bother with the domain concept as it really goes out the window. So then it=E2=80=99s just an exception to allow SRv6 to do as they please a= s impossible to control at that point so any and all use cases of SRv6 would be granted the exception. As Robert mentioned that it=E2=80=99s the carriers domain so they have to t= ake care of any security issues related to AH on the SRv6 outer IPV6 transport header. Also as noted by Robert that all customer traffic is kept in tact and not altered and that no insertion or removal of any EH headers occurs to the inner header customer payload. So no impact to customers use of AH etc as that is remains unaltered. Thanks Gyan On Fri, May 8, 2020 at 7:06 PM Robert Raszuk wrote: > Hi Philip, > > Sounds very reasonable. > > IMO what is needed here is a short spec which would explicitly call out > the case of using IPv6 as transport layer. Then it would allow the > transport owner sufficient flexibility (insertion, modification, deletion= ) > into applied by his own ingress new IPv6 header at any transit hop he see= ms > required. Ultimate goal is to deliver carried payload (here original IPv6 > or IPv4 packets) via a given network the best quality possible. > > Thx a lot, > Robert. > > > On Sat, May 9, 2020 at 12:42 AM Philip Homburg < > pch-ipv6-ietf-6@u-1.phicoh.com> wrote: > >> >Now comes the topic of an additional hander mangling even by nodes whic= h >> >are not intermediate destinations, yet all within transit network. >> >> So this is the key point. RFC 8200 applies to all IPv6 packets. So if >> RFC 8200 allows additional header mangling, then that can happen in lots >> of >> other places as well, which is quite undesirable. >> >> So RFC 8200 has to state that in general this sort of thing cannot happe= n. >> Next we can update RFC 8200 with a narrowly crafted exception tailored t= o >> this use case. >> >> We have two possibilities: >> - either RFC 8200 allows mangling by hops in a routing header. In that >> case we have a problem that needs to be fixed while creating an >> exception >> for segment routing, or >> - RFC 8200 does not allow this kind of mangling and we need to create an >> exception for segment routing. >> >> >> -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --00000000000059f53805a52b59b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Given that SRv6 PGM draft has left the sta= tion awaiting publication I think the most prudent recourse for 6MAN is to = grant the exception for SRV6 technology to allow insertion and removal on a= ny transit node within the carriers administrative domain. =C2=A0

<= th style=3D"box-sizing:border-box;padding:3px;line-height:1.42857143;vertic= al-align:top;border-top-width:0px;width:6em"><= /tr><= tr style=3D"box-sizing:border-box">
DocumentTypeActive Internet-Draft (spring WG)
Last updated2020-04-14 (latest revision 2020-03-27)
Replacesdraft-filsfils-spring-srv6= -network-programming
StreamIET= F
Intended RFC statusProposed Stan= dard
Formats=C2=A0plain text=C2=A0=C2=A0xml=C2=A0=C2=A0pdf=C2=A0htmlized (tools)=C2=A0=C2=A0htmlized=C2=A0bibtex
Stream= WG state<= /th>Submitted to IESG for Publication
D= ocument shepherdBruno Decraene

In the ver= biage as to reasons why this being allowed is that SRv6 would always be use= d in a closed domain with standard security protection mechanisms at ingres= s and egress of the domain.=C2=A0 Domain definition would have to be define= d as a carriers administratrative domain where the carriers transport netwo= rk could span multiple ASs that are inter connected via SR-TE bsid or inter= -as L3 vpn.=C2=A0

One ca= veat loophole does exist is that inter administrative domain intent based S= R flows would also be allowed so in theory you could have a chain of SRV6 d= omains over the internet or even private inter connected domains so then ma= ybe not bother with the domain concept as it really goes out the window. = =C2=A0

So then it=E2=80= =99s just an exception to allow SRv6 to do as they please as impossible to = control at that point so any and all use cases of SRv6 would be granted the= exception.

As Robert me= ntioned that it=E2=80=99s the carriers domain so they have to take care of = any security issues related to AH on the SRv6 outer IPV6 transport header.= =C2=A0

Also as noted by = Robert that all customer traffic is kept in tact and not altered and that n= o insertion or removal of any EH headers occurs to the inner header custome= r payload.=C2=A0 So no impact to customers use of AH etc as that is remains= unaltered.

Thanks=C2=A0=

Gyan




On Fri, May 8, 202= 0 at 7:06 PM Robert Raszuk <robert@= raszuk.net> wrote:
Hi Philip,

Sounds very reasonable.=C2=A0
<= div>
IMO what is needed here is a short spec which would expl= icitly call out the case of using IPv6 as transport layer. Then it would al= low the transport owner sufficient flexibility (insertion, modification, de= letion) into applied by his own ingress new IPv6 header at any transit hop = he seems required. Ultimate goal is to deliver carried payload (here origin= al IPv6 or IPv4 packets) via a given network the best quality possible.=C2= =A0

Thx a lot,
Robert.


On S= at, May 9, 2020 at 12:42 AM Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com&= gt; wrote:
>N= ow comes the topic of an additional hander mangling even by nodes which
>are not intermediate destinations, yet all within transit network.

So this is the key point. RFC 8200 applies to all IPv6 packets. So if
RFC 8200 allows additional header mangling, then that can happen in lots of=
other places as well, which is quite undesirable.

So RFC 8200 has to state that in general this sort of thing cannot happen.<= br> Next we can update RFC 8200 with a narrowly crafted exception tailored to this use case.

We have two possibilities:
- either RFC 8200 allows mangling by hops in a routing header. In that
=C2=A0 case we have a problem that needs to be fixed while creating an exce= ption
=C2=A0 for segment routing, or
- RFC 8200 does not allow this kind of mangling and we need to create an =C2=A0 exception for segment routing.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--
<= div dir=3D"ltr">

Gyan= =C2=A0 Mishra

Network Engineering & Technology= =C2=A0

Verizon=C2=A0

Silver Spring, MD 20= 904

Phone: 301 502-1347

<= font size=3D"1" color=3D"#000000" face=3D"georgia, serif">Email: gyan.s.mishra@verizon.= com



--00000000000059f53805a52b59b1-- From nobody Fri May 8 16:33:15 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3EF3A0E0E for ; Fri, 8 May 2020 16:33:14 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saruGJE4M2I3 for ; Fri, 8 May 2020 16:33:11 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 B78443A0E8D for ; Fri, 8 May 2020 16:33:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49Jmpv3TfVz1ntN4; Fri, 8 May 2020 16:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1588980791; bh=WpF+/n+/45D40os0VE4xEEwm3kt8xCm9xeVBR5RnAN8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YdZX4RCRPpYufKK5KQZ+QqNmVX4Ox2wlQlMRgN0v7xDipGUqNnY9bH0uzjiH5tAAR DSmmevUmVx6099GAy5i4q+lqZJ1LF5EGTFig/3d7NDgvFYyiJ1rk0b+b+yg3eFNIW3 Ye/0cJnKm9q1lqrpfWIHcnbxY1JpkQvl9CTwir34= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 49Jmpt73Ksz1nsxx; Fri, 8 May 2020 16:33:10 -0700 (PDT) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Gyan Mishra Cc: 6man WG References: From: "Joel M. Halpern" Message-ID: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> Date: Fri, 8 May 2020 19:33:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:33:14 -0000 The SRv6 PGM document that was approved does not do arbitrary insertion. It does the very specific PSP removal. I think it inappropriate for us to say that given that this one piece was allowed, anything and everything should be allowed. Also, it is normal for RFCs to be understood to be only applicable going forward. The most that should be said about PSP in this draft explicitly would be a note indicating that the PSP behavior predates this, and is not affected by it. And even that much would wait on the resolution of the pending appeal on the topic. Yours, Joel On 5/8/2020 7:27 PM, Gyan Mishra wrote: > > Given that SRv6 PGM draft has left the station awaiting publication I > think the most prudent recourse for 6MAN is to grant the exception for > SRV6 technology to allow insertion and removal on any transit node > within the carriers administrative domain. > > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ > > Document Type Active Internet-Draft (spring WG > ) > Last updated 2020-04-14 (latest revision 2020-03-27) > Replaces draft-filsfils-spring-srv6-network-programming > > Stream IETF > Intended RFC status Proposed Standard > Formats  plain text > >  xml > >  pdf >  htmlized > (tools) > >  htmlized >  bibtex > > Stream WG state > Submitted to IESG for Publication > Document shepherd Bruno Decraene > > > In the verbiage as to reasons why this being allowed is that SRv6 would > always be used in a closed domain with standard security protection > mechanisms at ingress and egress of the domain.  Domain definition would > have to be defined as a carriers administratrative domain where the > carriers transport network could span multiple ASs that are inter > connected via SR-TE bsid or inter-as L3 vpn. > > One caveat loophole does exist is that inter administrative domain > intent based SR flows would also be allowed so in theory you could have > a chain of SRV6 domains over the internet or even private inter > connected domains so then maybe not bother with the domain concept as it > really goes out the window. > > So then it’s just an exception to allow SRv6 to do as they please as > impossible to control at that point so any and all use cases of SRv6 > would be granted the exception. > > As Robert mentioned that it’s the carriers domain so they have to take > care of any security issues related to AH on the SRv6 outer IPV6 > transport header. > > Also as noted by Robert that all customer traffic is kept in tact and > not altered and that no insertion or removal of any EH headers occurs to > the inner header customer payload.  So no impact to customers use of AH > etc as that is remains unaltered. > > Thanks > > Gyan > > > > > On Fri, May 8, 2020 at 7:06 PM Robert Raszuk > wrote: > > Hi Philip, > > Sounds very reasonable. > > IMO what is needed here is a short spec which would explicitly call > out the case of using IPv6 as transport layer. Then it would allow > the transport owner sufficient flexibility (insertion, modification, > deletion) into applied by his own ingress new IPv6 header at any > transit hop he seems required. Ultimate goal is to deliver carried > payload (here original IPv6 or IPv4 packets) via a given network the > best quality possible. > > Thx a lot, > Robert. > > > On Sat, May 9, 2020 at 12:42 AM Philip Homburg > > wrote: > > >Now comes the topic of an additional hander mangling even by > nodes which > >are not intermediate destinations, yet all within transit > network. > > So this is the key point. RFC 8200 applies to all IPv6 packets. > So if > RFC 8200 allows additional header mangling, then that can happen > in lots of > other places as well, which is quite undesirable. > > So RFC 8200 has to state that in general this sort of thing > cannot happen. > Next we can update RFC 8200 with a narrowly crafted exception > tailored to > this use case. > > We have two possibilities: > - either RFC 8200 allows mangling by hops in a routing header. > In that >   case we have a problem that needs to be fixed while creating > an exception >   for segment routing, or > - RFC 8200 does not allow this kind of mangling and we need to > create an >   exception for segment routing. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- > > Gyan  Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: gyan.s.mishra@verizon.com > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri May 8 16:35:05 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04643A1095 for ; Fri, 8 May 2020 16:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 mWxjK-k1B7hk for ; Fri, 8 May 2020 16:35:00 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 A73303A1072 for <6man@ietf.org>; Fri, 8 May 2020 16:34:59 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id j4so2852219otr.11 for <6man@ietf.org>; Fri, 08 May 2020 16:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=D0fF+VD+0H5kuheLHrGnxtNwRKbEBY/vD1unMyQlRgk=; b=FlJTjO/oL5dMi6XnhLXe4aoFO/iAMRN+ygQsd9uOzy8FO5jVwXH3ab2CPR+q/eRElf bMzN0Cd4aPkat1bqMPNWTwjzczaC8V6nK8zKYfCrWZbq6X1rUw/eYrtKXT7JczIPJPVg V8Fu8WpxS7hbZUQB3ybvZUR2MzVED9wlSfVA4iLGVn6DUZZpVQiN2iZWTmK0r/4WVWt9 SbcGTK8QaqaCa8BxqYgq06CLmg+fRJBm4s9OVTAS2kefGs9LRe1UwZjHAO023upcft0a FZVpsl4ndYn3hvd1YpcC7E4SFp2FlUD3eZr0EmylgkJYb+psHCD/dgPAQv3tREh4K2Sq /Wyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=D0fF+VD+0H5kuheLHrGnxtNwRKbEBY/vD1unMyQlRgk=; b=AEtW4j0Wr6KZTftZ6QfhPpG0t3aSyhc87YSttuqFhiH4pcbnfYE+8S37CA1QyfDHg2 L1t3PmCdR6bCqj8JAHL2x2TkhtBWlleO0jCaQYFtsLUev9Gtmy9WMIxbo9pGI6DnLLNy iJYh74D3dsE02DljRM1u4ROeQMjMz9mjklrxl27m2k3fuFKgrFzpxu38eKhmwVtmsi1c vJx99RC0IAAb9bAmoXK9MMDgudTN/tUp7imBDAiD0HuW/Y9Yud16BbZ3FXdciC4qtz7C rZEyy+d9gN5Bl/+c9G6UUHEjMxFWQNFrumZXByk+6dl79le2l9J62+4+kva8LSj8k8Jc qSMw== X-Gm-Message-State: AGi0PuYNq7Mwg524sW8F57gBk4fN0DLOV5vlADwKCQ3GPHqdDdgLn7h/ fjdxIZyqedJD9i6UH2LWCqD0E8BDcBh0U/bQ5/mmyfcw X-Google-Smtp-Source: APiQypIhrRBlWpcLyS5U8XnSMSdgjuumqoT4lmFVKzofBXkz66wDnijLyVNqbJlXUot6uFCM9qCA8oLRX3ZmTTVCMmw= X-Received: by 2002:a05:6830:20d8:: with SMTP id z24mr4359588otq.74.1588980898799; Fri, 08 May 2020 16:34:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Sat, 9 May 2020 09:34:31 +1000 Message-ID: Subject: Re: Routing Header Insertion To: Ron Bonica Cc: Robert Raszuk , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:35:04 -0000 On Fri, 8 May 2020, 03:47 Ron Bonica, wrote: > > Robert, > > > > The problem is that the IPv6 destination address contains 5 uSID that rep= resent 5 nodes yet to be visited. Those need to be put at the end of the li= ne, so that they are visited *after* the nodes in the repair path. > > > > Yes, there are some very clever solutions that you and I understand. But = will the guy in the NOC who doesn=E2=80=99t live and breath SR be able to f= igure it out the first time he sees it. In some of these proposals, there doesn't seem to be any appreciation of the operational importance of predictable, simple and obvious operation (the principle of least surprise), compliance and compatibility with existing and already widely deployed standards compliant implementations, robustness against predictable faults like partial hardware failures, operator misconfiguration or vendor implementation bugs, nor the importance of being able to identifying the cause of a fault as soon as possible and being able to rectify it as quickly as possible once identified. A mechanism being able to work in a test lab, or being interoperable with another implementation in a test environment, doesn't provide any evidence that it will be easy and simple to operate in a production network with paying customers, nor quick to troubleshoot and fix when it breaks. Being able to be made to work and being interoperable with another implementation are relatively low bars if the goal is production network deployment. It works, but it may not work well. Regards, Mark. > > > = Ron > > > > > > > > Juniper Business Use Only > > From: Robert Raszuk > Sent: Thursday, May 7, 2020 1:28 PM > To: Ron Bonica > Cc: Voyer, Daniel ; Eric Vyncke (evyncke) ; 6man <6man@ietf.org> > Subject: Re: Routing Header Insertion > > > > [External Email. Be cautious of content] > > > > Hi Ron, > > > > > Yes, the problem can be solved, but not without deep though and vigoro= us head scratching. > > > > Well don't we still have the indicators of Active, Next and Last uSIDs in= SRH ? If so what is so difficult if you keep your original SRH as is and p= rovide FRR using new SRH ? Moreover if you POP the additional SRH @ ptotect= ied path PHP FRR endpoint may not even noticed he is acting as such endpoin= t and that is very cool thing. > > > > The problem perhaps becomes a nice exercise to solve how to handle TI-LFA= when you have uSID list in DA address of the packets and where there is no= SRH at all :) Clearly a valid deployment scenario. But since you are alrea= dy deep into it I will let you figure it out :) > > > > > When a solution is that complex, it is probably beyond the capability o= f any operations staff. > > > > Well it would be a mistake to count on all operators doing this handling = in P4 code on their own custom platforms. For rest of them a simple knob wo= uld be sufficient to enable it and enjoy. > > > > Thx, > > R. > > > > > > On Thu, May 7, 2020 at 7:03 PM Ron Bonica wrote: > > Hi Daniel, > > > > TI-LFA with SRH insertion poses problems in the following cases: > > > > When the packet already contains an SRH > When the IPv6 Destination Address contains uSIDs > > > > In the first case, when the packet already contains an SRH, TI-LFA with S= RH insertion results in a single packet that contains two SRH=E2=80=99s. No= reading of RFC 8200 allows this. > > > > The second case is more complex. Assume that in your uSID strategy: > > > > The uSID block identifier is 32 bits long > Each uSID is 16 bits long > The end-of-carrier marker is also 16 bits long > > > > In this case, you can fit 5 uSIDs in the IPv6 address. > > > > On the first segment, when the destination address still contains 5 uSIDs= , a PLR detects link failure and invokes TI-LFA procedures. The repair tunn= el contains 3 segments. If the PLR executes TI-LFA with insertion procedure= s, what does the resulting IPv6 Destination address look like? What does th= e SRH look like? > > > > Yes, the problem can be solved, but not without deep though and vigorous = head scratching. When a solution is that complex, it is probably beyond the= capability of any operations staff. > > > > The above-mentioned problems could have been avoided if TI-LFA created it= s repair tunnel by prepending an IPv6 header with its own SRH. > > > > = Ron > > > Juniper Business Use Only > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri May 8 16:40:11 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D6F3A005D for ; Fri, 8 May 2020 16:40:09 -0700 (PDT) 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, 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=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeIuxmQEedxp for ; Fri, 8 May 2020 16:40:08 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 2EA603A005C for ; Fri, 8 May 2020 16:40:08 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id s9so2722139eju.1 for ; Fri, 08 May 2020 16:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mmccbgxux7wgvYCgxGqQyy2RWB2dEnfZxNjtM8n/MGY=; b=UG0DDzAmLoXtudUgDYBRZ+wjxNrOe84Wy+pb9+KqP54GwDDQ+lfqtuaRwGgXZUJ6zY RChQ4ImyIbOz1fw3lb0gstpcofcjHNMDuGdH+vnwWztWzoy/J1xXL/9ukKf/1/QKV9Ro L2nYx+cmrMftW0aKWkbNUFOBAMECig7HMEpjH3hpkgqrjXNS2bR7D8xWhhkWQ1ketIPJ bKMqlUQXD4lCtRzmKpU7SW2VWqQAGk66k7lfRQoQH5QMoL1FOa/bPVOz4dpXsDpgLtrF nGcgy79GhP2raAZQc6InmLMn4MN0xa2/RMaqCjEBcuPQMz72/ypLQbjehmR8PJ5uI6ym /HpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mmccbgxux7wgvYCgxGqQyy2RWB2dEnfZxNjtM8n/MGY=; b=t7ABlkwFO2lN3VzENkyasZa+7r3imtnuLeoc/BYQ2srPadlC17S06TpEN3w5ABvUBN iBqi4+WkzYSo76JvkqeSVmgs7llTt3t2Hv7yfFlgbgPSOXSROYCin/F8X+/zuIsIqjK0 sTqE/kRsdk8pgNgs/X7cPzw3l2fxCHzqfZ6+vmYupw3k7MSz8M+DbEBEg+Po5h7CHFL0 88W9B6+0rE13zOAbGJOuis/NbD6S/PFjnG1+VD/gYusDEthdrnN6xdYDDk3cITPR5ijr gbFinO359BJoyJ/x+jQRcscoo51Cb/QWIr6oQ115+5iLSEBRRSuJ0U3ZWEcq4yAmqUE0 Lo2w== X-Gm-Message-State: AGi0PuY4yN7B8R6Fc3+CQyvDqULadsu1CJcYaEGVG+027zQnLQSJ/QYj RYrTgS5TO77KwZgQM8hOwr9cQIzMWhEEk7pIV7t5va5Q X-Google-Smtp-Source: APiQypIR6vx24Mn7YY83xmOLiBOQMWcZKDISILo5JGrsASgaa40NIhIczbEcY/ndk/RIjQzW9L05hY0RauFJcR64NFs= X-Received: by 2002:a17:906:328c:: with SMTP id 12mr3774623ejw.69.1588981206433; Fri, 08 May 2020 16:40:06 -0700 (PDT) MIME-Version: 1.0 References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> In-Reply-To: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> From: Robert Raszuk Date: Sat, 9 May 2020 01:39:57 +0200 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: "Joel M. Halpern" Cc: Gyan Mishra , 6man WG Content-Type: multipart/alternative; boundary="0000000000005d4c1505a52b84eb" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:40:10 -0000 --0000000000005d4c1505a52b84eb Content-Type: text/plain; charset="UTF-8" > And even that much would wait on the resolution of the pending appeal on > the topic. > If we would decouple end to end IPv6 from encapsulated transport IPv6 as well as allow required flexibility in the transport part there would no longer be any basis for the appeal. Where does it say that we must wait for the result of the appeal if WG would like to propose the solution which turns the entire appeal in progress into a moot point ? Thx, R. --0000000000005d4c1505a52b84eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0
And even that much would wait on the re= solution of the pending appeal on
the topic.

If we would decouple end to = end IPv6 from encapsulated transport IPv6 as well as allow required flexibi= lity in the transport part there would no longer be any basis for the appea= l.=C2=A0

Where does it say that we must wait for t= he result of the appeal if WG would like to propose the solution which turn= s the entire appeal in progress into a moot point ?=C2=A0

Thx,
R.

--0000000000005d4c1505a52b84eb-- From nobody Fri May 8 16:46:44 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03683A0064 for ; Fri, 8 May 2020 16:46:38 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wm7skHXhyv0y for ; Fri, 8 May 2020 16:46:31 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 53FBD3A005D for ; Fri, 8 May 2020 16:46:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49Jn6G0N1Lz1ntQt; Fri, 8 May 2020 16:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1588981590; bh=3C4c0b6goFfdy0udCPJzx3F3P0wQ4GA5WujdTvZd8x0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Y5IYRcZ+1veE6BGWAaC71JqM0ze273iI9WqfRp5YfNR2PCTsJxYPtiXHbxYzwWPL5 psSkJkLiLW9m5IXjfZ9pBpCZvWD9+aJMqptLzmq5lfO3baXwXurF+sDszxjNcA1k/a YZ844BFm/p0HNaGMnmQ1Xrymeb+9NT3rr/5Abhrw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 49Jn6F3v4Wz1ntPy; Fri, 8 May 2020 16:46:29 -0700 (PDT) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Robert Raszuk Cc: 6man WG References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <7f245a33-e8a0-8183-0942-57cfef67d803@joelhalpern.com> Date: Fri, 8 May 2020 19:46:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:46:41 -0000 Robert, the usage of IPv6 as a Transport is not different from other uses of IPv6. While there are times when we allow some behaviors in controlled domains, we do not consider that an arbitrary get-out-of-jail free card. In particular, a controlled domain does not solve most of the problems with header insertion or removal. Also, A transport tunnel is not the same as a controlled domain, so the use of IPv6 for a tunnel would do even less to relax the rules of 8200. The one thing the use of an IPv6 tunnel does achieve, and is already understood and accepted, is that because it is a new IPv6 header, the creator of that header gets to choose what they put in it, and the terminator is allowed to remove it. Yours, Joel On 5/8/2020 7:39 PM, Robert Raszuk wrote: > And even that much would wait on the resolution of the pending > appeal on > the topic. > > > If we would decouple end to end IPv6 from encapsulated transport IPv6 as > well as allow required flexibility in the transport part there would no > longer be any basis for the appeal. > > Where does it say that we must wait for the result of the appeal if WG > would like to propose the solution which turns the entire appeal in > progress into a moot point ? > > Thx, > R. > From nobody Fri May 8 16:57:56 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0903A011F for ; Fri, 8 May 2020 16:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 220y_vKzO662 for ; Fri, 8 May 2020 16:57:47 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A773A00DC for ; Fri, 8 May 2020 16:57:47 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id c3so2893989otp.8 for ; Fri, 08 May 2020 16:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=a8R5irlWOgDl95l4aL0Dlall457vt4mNfFPo6vHeIk8=; b=ETb4+45u7SSHwS+arWoLWFdU4v67N68Siyq9b6Fo0GaFf6L+Jh/Dbp+l/RGHd3VLh3 ypuZUNSdDwLqMI7LkuWvbPCWjfKfREh3SlqnOQ+jJFG8Kc0VOpWj63/6pQ3RabQSD3hM 8bebqLRVaafS3drT0qw/6SWLgByxWE1ekDKWErRCULHnw18Opnie2QJ06lWHGQZCiNxO nD4RyUf46v5E+l0cCIvR95LtRzz9I3wPbxs5bsJHZZSlxy1QR0Q8q1aBQNJUf68nz3ld mmcbrRdR9wWrhIjgUW2Va3PzM6vY6DWUprOA8pN9Fceo48H+xKLgCcaFb2LQsWt8fWnF BTOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=a8R5irlWOgDl95l4aL0Dlall457vt4mNfFPo6vHeIk8=; b=Cslz89NQoW3xGGrl5dfdx+tTSUQAzqCn9Gedh6hDuNxfuydbfwqA7fw6+J3seEeleZ va+uWRW92Hx/7+GJNpOKh5PB0Y5xGwGh/pBvCxQhlGESJeAX5hQOmB0pPaBk4zvg1pDo jipji+AVyZiBrkwGD6yno1OcBw3PuWGlfuYcVCDR5t2pUDGkMeR9x0zSHURQGHZDPX72 KL2YVeEyURER7QdpyJfjgKJjguPF2TLdceIwi7p7BxwqQD9SeV1x/B7LY6Rem3Lp3pmq aRCF+3jiQifiSA/InlkB7bmnjiXG7HVebquHo7ey3o8XBo3JpuccDGNvSCpBOhWHB7z8 gx0A== X-Gm-Message-State: AGi0PuYOuhC/m95RSHoVFo7XqqVChVYjZD7keDtg+O1y++TClEltzTCx absd5WqEktgL20GVmJgrD5P4EKW4Bm9Z/mQYANQ= X-Google-Smtp-Source: APiQypKIjMoDIaMfT7UyfOdVppP3lP6SYo9pjN/TNljdTr1Q2sUiI2xJSNK/HLqutqBNGO9ionr3DN/bgOqt5Ic2DqU= X-Received: by 2002:a05:6830:2091:: with SMTP id y17mr4389083otq.153.1588982266230; Fri, 08 May 2020 16:57:46 -0700 (PDT) MIME-Version: 1.0 References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> In-Reply-To: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> From: Mark Smith Date: Sat, 9 May 2020 09:57:19 +1000 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: "Joel M. Halpern" Cc: Gyan Mishra , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:57:53 -0000 On Sat, 9 May 2020 at 09:33, Joel M. Halpern wrote: > > The SRv6 PGM document that was approved does not do arbitrary insertion. > It does the very specific PSP removal. I think it inappropriate for > us to say that given that this one piece was allowed, anything and > everything should be allowed. > The trouble is that now that there is now implicit permission to do so. "What you allow, you encourage." - Michael Josephson. Any special use case will now be used to justify IPv6 packet mangling. Any working group other than 6man will now be able to take IPv6 and modify it to suit what they want to do, ignoring the specs and the 6man WG's intent, using PSP and what SPRING has been allowed to do to justify it. > Also, it is normal for RFCs to be understood to be only applicable going > forward. The most that should be said about PSP in this draft > explicitly would be a note indicating that the PSP behavior predates > this, and is not affected by it. > > And even that much would wait on the resolution of the pending appeal on > the topic. > > Yours, > Joel > > On 5/8/2020 7:27 PM, Gyan Mishra wrote: > > > > Given that SRv6 PGM draft has left the station awaiting publication I > > think the most prudent recourse for 6MAN is to grant the exception for > > SRV6 technology to allow insertion and removal on any transit node > > within the carriers administrative domain. > > > > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-program= ming/ > > > > Document Type Active Internet-Draft (spring WG > > ) > > Last updated 2020-04-14 (latest revision 2020-03-27) > > Replaces draft-filsfils-spring-srv6-network-progra= mming > > > > Stream IETF > > Intended RFC status Proposed Standard > > Formats plain text > > > > xml > > > > pdf > > htmlized > > (tools) > > > > htmlized > > bibtex > > > > Stream WG state > > Submitted to IESG for Publication > > Document shepherd Bruno Decraene > > > > > > In the verbiage as to reasons why this being allowed is that SRv6 would > > always be used in a closed domain with standard security protection > > mechanisms at ingress and egress of the domain. Domain definition woul= d > > have to be defined as a carriers administratrative domain where the > > carriers transport network could span multiple ASs that are inter > > connected via SR-TE bsid or inter-as L3 vpn. > > > > One caveat loophole does exist is that inter administrative domain > > intent based SR flows would also be allowed so in theory you could have > > a chain of SRV6 domains over the internet or even private inter > > connected domains so then maybe not bother with the domain concept as i= t > > really goes out the window. > > > > So then it=E2=80=99s just an exception to allow SRv6 to do as they plea= se as > > impossible to control at that point so any and all use cases of SRv6 > > would be granted the exception. > > > > As Robert mentioned that it=E2=80=99s the carriers domain so they have = to take > > care of any security issues related to AH on the SRv6 outer IPV6 > > transport header. > > > > Also as noted by Robert that all customer traffic is kept in tact and > > not altered and that no insertion or removal of any EH headers occurs t= o > > the inner header customer payload. So no impact to customers use of AH > > etc as that is remains unaltered. > > > > Thanks > > > > Gyan > > > > > > > > > > On Fri, May 8, 2020 at 7:06 PM Robert Raszuk > > wrote: > > > > Hi Philip, > > > > Sounds very reasonable. > > > > IMO what is needed here is a short spec which would explicitly call > > out the case of using IPv6 as transport layer. Then it would allow > > the transport owner sufficient flexibility (insertion, modification= , > > deletion) into applied by his own ingress new IPv6 header at any > > transit hop he seems required. Ultimate goal is to deliver carried > > payload (here original IPv6 or IPv4 packets) via a given network th= e > > best quality possible. > > > > Thx a lot, > > Robert. > > > > > > On Sat, May 9, 2020 at 12:42 AM Philip Homburg > > > > wrote: > > > > >Now comes the topic of an additional hander mangling even by > > nodes which > > >are not intermediate destinations, yet all within transit > > network. > > > > So this is the key point. RFC 8200 applies to all IPv6 packets. > > So if > > RFC 8200 allows additional header mangling, then that can happe= n > > in lots of > > other places as well, which is quite undesirable. > > > > So RFC 8200 has to state that in general this sort of thing > > cannot happen. > > Next we can update RFC 8200 with a narrowly crafted exception > > tailored to > > this use case. > > > > We have two possibilities: > > - either RFC 8200 allows mangling by hops in a routing header. > > In that > > case we have a problem that needs to be fixed while creating > > an exception > > for segment routing, or > > - RFC 8200 does not allow this kind of mangling and we need to > > create an > > exception for segment routing. > > > > > > -------------------------------------------------------------------= - > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------= - > > > > -- > > > > Gyan Mishra > > > > Network Engineering & Technology > > > > Verizon > > > > Silver Spring, MD 20904 > > > > Phone: 301 502-1347 > > > > Email: gyan.s.mishra@verizon.com > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri May 8 17:05:25 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330853A048D for ; Fri, 8 May 2020 17:05:16 -0700 (PDT) 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, 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=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu3FuPZ2wZTN for ; Fri, 8 May 2020 17:05:08 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71EE23A0496 for ; Fri, 8 May 2020 17:05:07 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id d16so2760875edv.8 for ; Fri, 08 May 2020 17:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lQkmTALxuSmCHjuQjwBR776xVONQEjPZmKLRkoRYa0Q=; b=eoGFxxBVpZw38wOLwmmsvdnfjCmWy3ADrj70aq1YlXARwimcbzvPq7UybXF8jXL5uQ uO3FEjGYTAvyb8qlAbHx9FNeT2zHYRoS5lXcD7ieu4OLdXKpG1WVN9rZHAUrQMUMdbUb WgqeZLsNTQWKPHD/7+WRaxYG1zq5RB8wCoDvJ3Kny3oh/FPngeY9P23EPsqkS6GRmyFO iNmH5He8dIbkUw1BSt844+W8eiA8W1UTqqw1kbdNhSL7dbLGvG6SIahMJRAYQdPe8Bjo w929MqEQiAlXoCHw4kSvb8MhH8Iewu81Vmffx/UtYW6Cr5w/iuc9GmjInu7vQ6vbIHMZ 78Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lQkmTALxuSmCHjuQjwBR776xVONQEjPZmKLRkoRYa0Q=; b=DSlA8UF2RMP+kJKGfj1560G8eUs2m4f1/ien0T5TIgpDcyunPSjgpTGfwBCIa8Yv+k eIhPkZMhOj+CQLIsnyI7aNelT0GUc16baFJbFZuPcSFtDc8fGzq8pJqanfZ9UOaZi7vk GqZL39HOHua2yWJW8NfZti62hmVw7BZGArquSfs6e3TNPWwXcMy1HM2nR0IkNaDfGkBN yUvtEY5dHgVlZqOSDMOaZWJXS0Q6hKgJHhTOVm0gmSWWr63Bx1C7shxt46YA++Ja5yEz 1f6c/DdsqJRR2wt50UNnCiDRwSfZCvFzk348Vd7nuSlKrzmdNRnMCumzCh938/ZN2Tqd akmg== X-Gm-Message-State: AGi0PuZXxrdUya3BsTGvfyk/4yGxEpKO6uGDjIGA/ZLEdr2MMOsWlfwi SZQTRJeeypSDQkHsyMAeJ8HeXN8aB5VkhhQQEU4LYA== X-Google-Smtp-Source: APiQypJHdME/K4seKBxUstFCn5Zcb8i38fWsiO92lSNc8rqTSboWFQjLYr118b8NlltE5kLUwIvSMEmT+CaszN7gA60= X-Received: by 2002:aa7:c5d1:: with SMTP id h17mr4385979eds.109.1588982705739; Fri, 08 May 2020 17:05:05 -0700 (PDT) MIME-Version: 1.0 References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> In-Reply-To: From: Robert Raszuk Date: Sat, 9 May 2020 02:04:56 +0200 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Mark Smith Cc: "Joel M. Halpern" , 6man WG Content-Type: multipart/alternative; boundary="000000000000baf05d05a52bdd94" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 00:05:23 -0000 --000000000000baf05d05a52bdd94 Content-Type: text/plain; charset="UTF-8" > > Any working group other than 6man will now be able to take IPv6 and > modify it to suit what they want to do, ignoring the specs and the > 6man WG's intent, using PSP and what SPRING has been allowed to do to > justify it. > And that to me sounds like a feature. The best protocols are those which are used way beyond their original author's intentions. Experience shows that we as humans are pretty bad in predicting the future so all we can is do to define things in an extensible style such that others may ride on it. If they would be denied to modify it and use it as it seems fit to realize their ideas - they would need to reinvent the wheel - not the best use of time. --000000000000baf05d05a52bdd94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Any working group other than 6man will now be able to ta= ke IPv6 and
modify it to suit what they want to do, ignoring the specs and the
6man WG's intent, using PSP and what SPRING has been allowed to do to justify it.

And that to me sounds like = a feature.=C2=A0

The best protocols are those whic= h are used way beyond their original author's intentions.=C2=A0

Experience shows that we as humans are pretty bad in pred= icting the future so all we can is do to define things in an extensible sty= le such that others may ride on it.=C2=A0

If they = would be denied to modify it and use it as it seems fit to realize their id= eas - they would need to reinvent=C2=A0the=C2=A0wheel - not the best use of= time.=C2=A0




=C2=A0
--000000000000baf05d05a52bdd94-- From nobody Fri May 8 17:35:22 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156F53A00C4 for ; Fri, 8 May 2020 17:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTEkNeJv3CXm for ; Fri, 8 May 2020 17:35:17 -0700 (PDT) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 78DBE3A00C0 for ; Fri, 8 May 2020 17:35:17 -0700 (PDT) Received: by mail-wr1-f52.google.com with SMTP id v12so3907681wrp.12 for ; Fri, 08 May 2020 17:35:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ovOZY1d0ca5zCf7b8t9R5bnbCkwjl/JD0L+Tlh+YufQ=; b=FMgQsSFBBQVH4YwFFyoM1VsYL1shr2/hhI2cHpk/UI3ViXYyKhESPVEqW9ldXrRaly t5v6Gr669ZG9t8c0WyFlvtZi0EKRoASnf3mYit/zWt619+UBgILfpk1HKGZzMDvWWAIh TIdzy2PGFJlw1elq21YaZh1wEuesoAWsVanO91M/RM43evX8O9vWNLHUmgrC2HJF+jlb jYSEKxDY4WDPxUaHm1+te2si/eaDAvdprQqgR/0Ivvu4Q5OtYmsFl5MVXsRu4NvH0zxk SezAiTdfYFLiBeNf5iyqP/ETUCP6GvLfKhVQlg3jJz+bHKSYfXTIBLyS3VyHIeApdIxf ISOw== X-Gm-Message-State: AGi0PuaKId7byOfi03D92uJLmSj6LtuR4l6MXuJVmOODHRxiPuuu1uw6 +lYCguZmiL9LrPKULlb5x6UnCNV3jWGVnHx95D4= X-Google-Smtp-Source: APiQypJsOIeLexfFLtsOx0T7VNdpYbFNG376gDYKPiso9ZDOeyPyeyxdKK+dRvQWjViCzyUV5vj36ZG/TWaGluKZZJE= X-Received: by 2002:a5d:6646:: with SMTP id f6mr5599462wrw.318.1588984515735; Fri, 08 May 2020 17:35:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 8 May 2020 17:35:04 -0700 Message-ID: Subject: whether to grant exception for SRV6 (Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03) To: Gyan Mishra Cc: Robert Raszuk , 6man WG Content-Type: multipart/alternative; boundary="0000000000009d343905a52c4907" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 00:35:20 -0000 --0000000000009d343905a52c4907 Content-Type: text/plain; charset="UTF-8" At Fri, 8 May 2020 19:27:53 -0400, Gyan Mishra wrote: > Given that SRv6 PGM draft has left the station awaiting publication I think > the most prudent recourse for 6MAN is to grant the exception for SRV6 > technology to allow insertion and removal on any transit node within the > carriers administrative domain. Could we at least change the subject, please? (I'm now actually changing it). As Ron already clarified, while the unfortunate discussion for draft-ietf-spring-srv6-network-programming was indeed a major background motivation of draft-bonica-6man-ext-hdr-update-03, whether 6man should grant the exception for SRV6 is irrelevant to it. It's for the general protocol spec, rather than whatever exceptions grated to the general protocol. But on a slightly related point on the relationship between these two: I don't think "SRv6 PGM draft has left the station awaiting publication" in the first place. It's not even in an IETF last call; it can be returned to the WG at the AD evaluation stage, and even if it passes the AD there will certainly be more discussions at the stage of IETF last call. It's not uncommon that a proposal that passes a WGLC is returned or even dropped in these phases. And, I'd certainly oppose it if and when the draft reaches an IETF last call in its current shape, since it's not distinguishable from an abuse of the text bug of RFC8200 for an easy shortcut, attempting to avoid tougher discussions. That's unfortunate especially because it seems to me that PGM has a pretty good chance of justifying it as an exception (though probably still controversial) and an update to RFC8200 in that sense, instead of claiming it's just already standard compliant. The expected meta discussion at that stage will be non-constructive, and I suspect it can even take more time than just trying to justify it as an exception/update due to its meta level controversy (in which case it's also unfortunate for those who just want it to be published sooner). My hope with draft-bonica-6man-ext-hdr-update-03 is that it will prevent such unnecessary and unfortunate discussions in future, if not for draft-ietf-spring-srv6-network-programming. -- JINMEI, Tatuya --0000000000009d343905a52c4907 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Fri, 8 May 2020 19:27:53 -0400,
Gyan Mishra <hayabusagsm@gmail.com> wrote:
> Given that SRv6 PGM draft has left the station awaiting publicat= ion I think
> the most prudent recourse for 6MAN is to grant the exce= ption for SRV6
> technology to allow insertion and removal on any tra= nsit node within the
> carriers administrative domain.

Could w= e at least change the subject, please? =C2=A0(I'm now actually
chang= ing it).

As Ron already clarified, while the unfortunate discussion = for
draft-ietf-spring-srv6-network-programming was indeed a major
bac= kground motivation of draft-bonica-6man-ext-hdr-update-03, whether
6man = should grant the exception for SRV6 is irrelevant to it.=C2=A0 It's
= for the general protocol spec, rather than whatever exceptions grated
to= the general protocol.

But on a slightly related point on the relati= onship between these two:
I don't think "SRv6 PGM draft has lef= t the station awaiting
publication" in the first place.=C2=A0 It= 9;s not even in an IETF last call;
it can be returned to the WG at the A= D evaluation stage, and even if
it passes the AD there will certainly be= more discussions at the stage
of IETF last call.=C2=A0 It's not unc= ommon that a proposal that passes a
WGLC is returned or even dropped in = these phases.=C2=A0 And, I'd certainly
oppose it if and when the dra= ft reaches an IETF last call in its
current shape, since it's not di= stinguishable from an abuse of the
text bug of RFC8200 for an easy short= cut, attempting to avoid tougher
discussions.=C2=A0 That's unfortuna= te especially because it seems to me
that PGM has a pretty good chance o= f justifying it as an exception
(though probably still controversial) an= d an update to RFC8200 in that
sense, instead of claiming it's just = already standard compliant.

The expected meta discussion at that sta= ge will be non-constructive,
and I suspect it can even take more time th= an just trying to justify
it as an exception/update due to its meta leve= l controversy (in which
case it's also unfortunate for those who jus= t want it to be published
sooner).=C2=A0 My hope with draft-bonica-6man-= ext-hdr-update-03 is that it
will prevent such unnecessary and unfortuna= te discussions in future,
if not for draft-ietf-spring-srv6-network-prog= ramming.

--
JINMEI, Tatuya
--0000000000009d343905a52c4907-- From nobody Fri May 8 18:22:45 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBBB3A058F for ; Fri, 8 May 2020 18:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.596 X-Spam-Level: X-Spam-Status: No, score=-0.596 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 DC9xml9h3bke for ; Fri, 8 May 2020 18:22:41 -0700 (PDT) Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 F243A3A0484 for ; Fri, 8 May 2020 18:22:40 -0700 (PDT) Received: by mail-oo1-xc29.google.com with SMTP id x17so742789ooa.3 for ; Fri, 08 May 2020 18:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DkwJ5Ur00Vv5pTyPfX9g3e913iceP/nPXTkphE54z9s=; b=Cy8mWXd0DCk+9knZip2SCpbvcq4iLgm4aLm5LAX3tZbufLcxeDTBWN62/V8FQB4RN0 i4cZQAUXrgVxlrlrPr6dWlEoFHj5mwacV0ESGldqtYb4ah83rr5DPTIeYvGhq2HOQk3F hTkPHVCLTuiqY6PiBzjBxCdYdviFG6F92p2WCQCUvL3hDEIySjRrf2ewZ4NT1a8CvtrR kN2uLd9HiOATCSaVFGzxv8V7vRHefXXksCQBdUrdCnf//QRcO/J5fUIHy3bF3bdO/Mge I5cBoObDbvfCVvnefMwC8pbfHINE8axievlD4vsJQlIWPYv+7XJ+iXTOyPEjD0UoZrUK jjCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DkwJ5Ur00Vv5pTyPfX9g3e913iceP/nPXTkphE54z9s=; b=MVrgkc/6Q9O1SQ43PS3zsNkEQnj+Iq1JWe+mY8yhV6GpBvSsApcQ0qIrXw6PpsBe8M 1BCsQTA3AzFnfH8wn0veNBf2e3ETqF9WoRYsCMB7agq7BWzLxFcTEriQFPyDTIbX6Xbm NA8fNPNq5aNS7FTS9KBdvht+887G2WMTWWnYhuItnq6vKFm1jxJM6DEifnWiaKbdVp1C W3t69k/+Oq6wA0DFwrjqDvX2zdDakg5C2/m44XKFGW45nuaN0BfdBDautIY9cO1cHG8A pfjTM5ntrsjJAL6FhY9AS+cxgIrcxrJALZw9L5rEcUmNQ0CxvnpClZiBMGeoF+xbwG/I vlcA== X-Gm-Message-State: AGi0PubdKUfBkkidQPJvYozIMLMN1vDjwb3+//C0eLIpJLEZxVpVE1eM L9nZcDmI2WyYSG/RbGddh8tm1QOqfg7IzM12Id0= X-Google-Smtp-Source: APiQypLYcNOfRJwcmdaSfhVK2O6Z699xjOQuji1crGhZMGJy3OOyQJv4z9JKKmopS2oKhniP3TJ5yMfJXqhBFzAlPdA= X-Received: by 2002:a4a:accf:: with SMTP id c15mr4936014oon.29.1588987359106; Fri, 08 May 2020 18:22:39 -0700 (PDT) MIME-Version: 1.0 References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> In-Reply-To: From: Mark Smith Date: Sat, 9 May 2020 11:22:12 +1000 Message-ID: Subject: Use/Modification/Extensibility and Reinvention (Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03) To: Robert Raszuk Cc: "Joel M. Halpern" , 6man WG Content-Type: multipart/alternative; boundary="000000000000179c2705a52cf379" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 01:22:43 -0000 --000000000000179c2705a52cf379 Content-Type: text/plain; charset="UTF-8" On Sat, 9 May 2020, 10:05 Robert Raszuk, wrote: > Any working group other than 6man will now be able to take IPv6 and >> modify it to suit what they want to do, ignoring the specs and the >> 6man WG's intent, using PSP and what SPRING has been allowed to do to >> justify it. >> > > And that to me sounds like a feature. > > The best protocols are those which are used way beyond their original > author's intentions. > > Modifying something is not using it. I have modified blade screw drivers to suit are special purpose. They're not blade screwdrivers anymore (they're bicycle wheel spoke nipple drivers), and cannot be used as blade screwdrivers. Modifying IPv6 is not using IPv6. > Experience shows that we as humans are pretty bad in predicting the future > so all we can is do to define things in an extensible style such that > others may ride on it. > > Extensibility is being able to add to something that already exists without interfering with the existing thing's operation. Modifying something that already exists and has fixed definitions, changing its behaviour, is not extensibility. There are areas where IPv6 is extensible, such as via the creation of new EHs, and other areas where it is not. > If they would be denied to modify it and use it as it seems fit to realize > their ideas - they would need to reinvent the wheel - not the best use of > time. > > > I don't think SPRING have tried that hard to follow this principle, because there are a number of examples where existing and proven mechanisms that work could have been used; instead reinvention occurred. uSID is trying to reinvent the purpose of the IPv6 Destination Address field, by encoding a set of multiple packet destinations in that field, despite the word "Address" being singular in RFC 8200. SRv6 Network Programming needs to reinvent IPv6 DA matching at the destination in 3. SRv6 SID because it doesn't assign SIDs (that have become IPv6 addresses) to interfaces, contrary to the RFC 4291 addressing architecture, which dictates that IPv6 addresses are assigned to interfaces not nodes. SPRING tried to reinvent the meaning of the No Next Header EH (type 59) to implicitly mean an Ethernet payload followed. SPRING needed to reinvent AH via the SRH HMAC TLV, because the operations being performed on IPv6 packets weren't compliant with RFC8200, and therefore AH couldn't be used. There may be a 5th example I can't quite remember right now. It has seemed to me that SPRING have had too much of a "greenfield" mentality, allowing other existing specs to be taken and casually modified, rather than proposing modifications only as a last resort, when there is no other way to make the function work within existing proven mechanisms. In all these cases changing SR methods to fit within the existing would have been far less time and effort than the reinvention that has occurred or was proposed. Regards, Mark. > > > --000000000000179c2705a52cf379 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, 9 May 2020, 10:05 Robert Rasz= uk, <robert@raszu= k.net> wrote:
Any working group other than 6man will now be able to take IPv6 and modify it to suit what they want to do, ignoring the specs and the
6man WG's intent, using PSP and what SPRING has been allowed to do to justify it.

And that to me sounds like = a feature.=C2=A0

The best protocols are tho= se which are used way beyond their original author's intentions.=C2=A0<= /div>


Modifying something is not using it.

<= /div>
I have modified blade screw drivers to suit are spec= ial purpose. They're not blade screwdrivers anymore (they're bicycl= e wheel spoke nipple drivers), and cannot be used as blade screwdrivers.

Modifying IPv6 is not using IPv6.=
=C2=A0
Experience shows th= at we as humans are pretty bad in predicting the future so all we can is do= to define things in an extensible style such that others may ride on it.= =C2=A0


Ext= ensibility is being able to add to something that already exists without in= terfering with the existing thing's operation. Modifying something that= already exists and has fixed definitions, changing its behaviour, is not e= xtensibility.

There are areas where IPv6 is extens= ible, such as via the creation of new EHs, and other areas where it is not.=
=C2=A0
=
If they would be denied to modif= y it and use it as it seems fit to realize their ideas - they would need to= reinvent=C2=A0the=C2=A0wheel - not the best use of time.=C2=A0
<= br>


I don&= #39;t think SPRING have tried that hard to follow this principle, because t= here are a number of examples where existing and proven mechanisms that wor= k could have been used; instead reinvention occurred.

<= div>uSID is trying to reinvent the purpose of the IPv6 Destination Address = field, by encoding a set of multiple packet destinations in that field, des= pite the word "Address" being singular in RFC 8200.

SRv6 Network Programming needs to reinvent IPv6 = DA matching at the destination in=C2=A03. SRv6 SID=C2=A0because it doesn't assign SI= Ds (that have become IPv6 addresses) to interfaces, contrary to the RFC 429= 1 addressing architecture, which dictates that IPv6 addresses are assigned = to interfaces not nodes.

SPRING tried to reinvent = the meaning of the No Next Header EH (type 59) to implicitly mean an Ethern= et payload followed.

SPRING needed to reinvent AH = via the SRH HMAC TLV, because the operations being performed on IPv6 packet= s weren't compliant with RFC8200, and therefore AH couldn't be used= .

There may be a 5th example I can't quite rem= ember right now.


It has seemed= to me that SPRING have had too much of a "greenfield" mentality,= allowing other existing specs to be taken and casually modified, rather th= an proposing modifications only as a last resort, when there is no other wa= y to make the function work within existing proven mechanisms.
<= div>
In all these cases changing SR methods to fit within the= existing would have been far less time and effort than the reinvention tha= t has occurred or was proposed.

Regards,
Mark.

=


= =C2=A0
--000000000000179c2705a52cf379-- From nobody Fri May 8 19:46:36 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C773A0844 for ; Fri, 8 May 2020 19:46:34 -0700 (PDT) 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 5hNfwJCKgMdH for ; Fri, 8 May 2020 19:46:31 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 6CA3B3A0843 for ; Fri, 8 May 2020 19:46:31 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id k18so3842178ion.0 for ; Fri, 08 May 2020 19:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RfAV+3TVlg7Jf69IdTrxwMwmw9SAr+0tHzEqgXIfykU=; b=n4XsqSTcPWXiG5DusoUTBqhemhvIEQdiGDq5rLgYr96tUtzYuN+D+7sLEdKPfNb7/e cpZsJT2NlRzhr59YvRNKCfELjMjHR7GVk/W/wpjSijSkdYXTrvGX10gaemMi0XrfmeeJ C4wGJvN3kuBUxepmPG/liugy27SWhJuUWkNGBSnPTqs2crTNVJIwuxHfI7ywRVHeOh3s eAzW4ejaIJJrI3/RzYCvmlwuVsmC701f/N2OkCOIFUKvsdqZ5BowLQYm/s+Emd2wlUhP SlT05f9QPthmNjqoe6DGA4habe38mL77ZQxf1W+By4v8+pFdOzp5hgMY39w31WZ79a54 Uy/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RfAV+3TVlg7Jf69IdTrxwMwmw9SAr+0tHzEqgXIfykU=; b=jZEARKSNqdcpr3vZd1V1/2Cbe/GBJfhS1ua5PknNlmsLKpqPzzmMvhWLv31fgmW3ah FS1tkENJPsTjYYVQi5sOSokn0B1C9R8xadBr0SI3JFkQBksosYC3CBqXuQjk4UalnTCq idASfeDdbuU0QJy0c1TtqPLj2tpFCBQqKxlUZ0AHQFHrqlNFx3IkqZ3UyexBmKb85Hf4 C+uUsnyz2enW3ou9TVLuAQzdjYADXIyORKDf1l8kF3iEsKK0bGbMVLRbWGNPLtv+fCKg aqq2bIHlqT5QmMHGcPOpJi79jTumjmghJ71ngWEOAgZC1mGgY38Jc2YtXidrgSqXsFad imFg== X-Gm-Message-State: AGi0PuZUzBHxgt+lrdYTTPJ2rtlnmvU+9BcNQkZlBGWQaTGZgLOCSN8y PHS8E43WVrHRTA3Zvy+npCQynvHI/bZstA2GxgHE5HVLyAE= X-Google-Smtp-Source: APiQypJ2tKSWc+5SIx5N+4Pb978BK/OoN78+GM8mlUelabe1kFuKHUSjUDiqXpqLM0O7/1+bSj/rXqRDU/migMU9abk= X-Received: by 2002:a02:90cd:: with SMTP id c13mr5495093jag.83.1588992390549; Fri, 08 May 2020 19:46:30 -0700 (PDT) MIME-Version: 1.0 References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> In-Reply-To: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> From: Gyan Mishra Date: Fri, 8 May 2020 22:46:19 -0400 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: "Joel M. Halpern" Cc: 6man WG Content-Type: multipart/alternative; boundary="000000000000fd550305a52e1e55" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 02:46:34 -0000 --000000000000fd550305a52e1e55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Joel Thanks for the correction. Sorry for any confusion. So there are tire spots in an SRv6 implementation where an SRH routing header type 4 is inserted. SRV6 source node - 1st 6in6 outer transport encapsulation- customer PE-CE traffic is tunneled inner payload TI-LFA - The latest version of the PGM draft was modified to fix this violation. FRR link and node protection backup path where at the PLR node EH header could be inserted on any transit node. This was the worst violator of RFC 8200. So the agreed upon solution to resolve this violation was to add another 6in6 encapsulation + SRH to steer bypass traffic to the merge point PQ node. The only remaining RFC 8200 violation was related to PSP the removal of the SRH on the PSP node is a violation and deemed a violation due SRH being removed on destination endpoint that is not the final destination endpoint SL=3D0. So what counts is the incoming SL=3D1 prior to the PSP node proces= sing and final destination Segment copies to DA. So we can be very explicit in the verbiage with regards to SRv6 intra domain PSP function exception. Gyan On Fri, May 8, 2020 at 7:33 PM Joel M. Halpern wrote: > The SRv6 PGM document that was approved does not do arbitrary insertion. > It does the very specific PSP removal. I think it inappropriate for > us to say that given that this one piece was allowed, anything and > everything should be allowed. > > Also, it is normal for RFCs to be understood to be only applicable going > forward. The most that should be said about PSP in this draft > explicitly would be a note indicating that the PSP behavior predates > this, and is not affected by it. > > And even that much would wait on the resolution of the pending appeal on > the topic. > > Yours, > Joel > > On 5/8/2020 7:27 PM, Gyan Mishra wrote: > > > > Given that SRv6 PGM draft has left the station awaiting publication I > > think the most prudent recourse for 6MAN is to grant the exception for > > SRV6 technology to allow insertion and removal on any transit node > > within the carriers administrative domain. > > > > > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programmi= ng/ > > > > Document Type Active Internet-Draft (spring WG > > ) > > Last updated 2020-04-14 (latest revision 2020-03-27) > > Replaces > draft-filsfils-spring-srv6-network-programming > > < > https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-network-progr= amming/ > > > > Stream IETF > > Intended RFC status Proposed Standard > > Formats plain text > > < > https://www.ietf.org/id/draft-ietf-spring-srv6-network-programming-15.txt= > > > > xml > > < > https://www.ietf.org/id/draft-ietf-spring-srv6-network-programming-15.xml= > > > > pdf > > < > https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-15.= pdf> htmlized > > > (tools) > > < > https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15= > > > > htmlized > > < > https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-prog= ramming-15> bibtex > > > < > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programmi= ng/bibtex > > > > Stream WG state < > https://datatracker.ietf.org/help/state/draft/ietf> > > Submitted to IESG for Publication > > Document shepherd Bruno Decraene > > > > > > In the verbiage as to reasons why this being allowed is that SRv6 would > > always be used in a closed domain with standard security protection > > mechanisms at ingress and egress of the domain. Domain definition woul= d > > have to be defined as a carriers administratrative domain where the > > carriers transport network could span multiple ASs that are inter > > connected via SR-TE bsid or inter-as L3 vpn. > > > > One caveat loophole does exist is that inter administrative domain > > intent based SR flows would also be allowed so in theory you could have > > a chain of SRV6 domains over the internet or even private inter > > connected domains so then maybe not bother with the domain concept as i= t > > really goes out the window. > > > > So then it=E2=80=99s just an exception to allow SRv6 to do as they plea= se as > > impossible to control at that point so any and all use cases of SRv6 > > would be granted the exception. > > > > As Robert mentioned that it=E2=80=99s the carriers domain so they have = to take > > care of any security issues related to AH on the SRv6 outer IPV6 > > transport header. > > > > Also as noted by Robert that all customer traffic is kept in tact and > > not altered and that no insertion or removal of any EH headers occurs t= o > > the inner header customer payload. So no impact to customers use of AH > > etc as that is remains unaltered. > > > > Thanks > > > > Gyan > > > > > > > > > > On Fri, May 8, 2020 at 7:06 PM Robert Raszuk > > wrote: > > > > Hi Philip, > > > > Sounds very reasonable. > > > > IMO what is needed here is a short spec which would explicitly call > > out the case of using IPv6 as transport layer. Then it would allow > > the transport owner sufficient flexibility (insertion, modification= , > > deletion) into applied by his own ingress new IPv6 header at any > > transit hop he seems required. Ultimate goal is to deliver carried > > payload (here original IPv6 or IPv4 packets) via a given network th= e > > best quality possible. > > > > Thx a lot, > > Robert. > > > > > > On Sat, May 9, 2020 at 12:42 AM Philip Homburg > > > > wrote: > > > > >Now comes the topic of an additional hander mangling even by > > nodes which > > >are not intermediate destinations, yet all within transit > > network. > > > > So this is the key point. RFC 8200 applies to all IPv6 packets. > > So if > > RFC 8200 allows additional header mangling, then that can happe= n > > in lots of > > other places as well, which is quite undesirable. > > > > So RFC 8200 has to state that in general this sort of thing > > cannot happen. > > Next we can update RFC 8200 with a narrowly crafted exception > > tailored to > > this use case. > > > > We have two possibilities: > > - either RFC 8200 allows mangling by hops in a routing header. > > In that > > case we have a problem that needs to be fixed while creating > > an exception > > for segment routing, or > > - RFC 8200 does not allow this kind of mangling and we need to > > create an > > exception for segment routing. > > > > > > -------------------------------------------------------------------= - > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------= - > > > > -- > > > > Gyan Mishra > > > > Network Engineering & Technology > > > > Verizon > > > > Silver Spring, MD 20904 > > > > Phone: 301 502-1347 > > > > Email: gyan.s.mishra@verizon.com > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > --=20 Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --000000000000fd550305a52e1e55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Joel

Thanks for the correction.=C2=A0 Sorry for any confusion= .

So there are tire spot= s in an SRv6 implementation where an SRH routing header type 4 is inserted.=

SRV6 source node - 1st = 6in6 outer transport encapsulation- customer PE-CE traffic is tunneled inne= r payload

TI-LFA - The l= atest version of the PGM draft was modified to fix this violation.=C2=A0 FR= R link and node protection backup path where at the PLR node EH header coul= d be inserted on any transit node.=C2=A0 This was the worst violator of RFC= 8200.=C2=A0 So the agreed upon solution to resolve this violation was to a= dd another 6in6 encapsulation + SRH to steer bypass traffic to the merge po= int PQ node.

The only re= maining RFC 8200 violation was related to PSP the removal of the SRH on the= PSP node is a violation and deemed a violation due SRH being removed on de= stination endpoint that is not the final destination endpoint SL=3D0.=C2=A0= So what counts is the incoming SL=3D1 prior to the PSP node processing and= =C2=A0 final destination Segment copies to DA.

=
So we can be very explicit in the verbiage with reg= ards to SRv6 intra domain PSP function exception.
Gyan


On Fri, May 8, 20= 20 at 7:33 PM Joel M. Halpern <jm= h@joelhalpern.com> wrote:
Th= e SRv6 PGM document that was approved does not do arbitrary insertion.
=C2=A0 It does the very specific PSP removal.=C2=A0 I think it inappropriat= e for
us to say that given that this one piece was allowed, anything and
everything should be allowed.

Also, it is normal for RFCs to be understood to be only applicable going forward.=C2=A0 The most that should be said about PSP in this draft
explicitly would be a note indicating that the PSP behavior predates
this, and is not affected by it.

And even that much would wait on the resolution of the pending appeal on the topic.

Yours,
Joel

On 5/8/2020 7:27 PM, Gyan Mishra wrote:
>
> Given that SRv6 PGM draft has left the station awaiting publication I =
> think the most prudent recourse for 6MAN is to grant the exception for=
> SRV6 technology to allow insertion and removal on any transit node > within the carriers administrative domain.
>
> https://datatracker= .ietf.org/doc/draft-ietf-spring-srv6-network-programming/
>
> Document=C2=A0 =C2=A0 =C2=A0 Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Active Internet-Draft (spring WG
> <https://datatracker.ietf.org/wg/spring/>)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Last updated=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 2020-04-14 (latest revision 2020-03-27)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Replaces=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 draft-filsfils-spring-srv6-network-programming
> <https://dat= atracker.ietf.org/doc/draft-filsfils-spring-srv6-network-programming/&g= t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IET= F
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Intended RFC status=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Proposed Standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Formats=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0plain text
> <https://www.ietf.o= rg/id/draft-ietf-spring-srv6-network-programming-15.txt>
>=C2=A0 =C2=A0xml
> <https://www.ietf.o= rg/id/draft-ietf-spring-srv6-network-programming-15.xml>
>=C2=A0 =C2=A0pdf
> <https://tools.i= etf.org/pdf/draft-ietf-spring-srv6-network-programming-15.pdf>=C2=A0= htmlized
> (tools)
> <https://tools.ietf= .org/html/draft-ietf-spring-srv6-network-programming-15>
>=C2=A0 =C2=A0htmlized
> <https://= datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15= >=C2=A0bibtex
> <https://d= atatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/bibtex>
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 WG state <
https://datatracker.ietf.org/help/state/draft/ietf>=C2=A0 =C2=A0 <= br> > Submitted to IESG for Publication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Document shepherd=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Bruno Decraene
>
>
> In the verbiage as to reasons why this being allowed is that SRv6 woul= d
> always be used in a closed domain with standard security protection > mechanisms at ingress and egress of the domain.=C2=A0 Domain definitio= n would
> have to be defined as a carriers administratrative domain where the > carriers transport network could span multiple ASs that are inter
> connected via SR-TE bsid or inter-as L3 vpn.
>
> One caveat loophole does exist is that inter administrative domain > intent based SR flows would also be allowed so in theory you could hav= e
> a chain of SRV6 domains over the internet or even private inter
> connected domains so then maybe not bother with the domain concept as = it
> really goes out the window.
>
> So then it=E2=80=99s just an exception to allow SRv6 to do as they ple= ase as
> impossible to control at that point so any and all use cases of SRv6 <= br> > would be granted the exception.
>
> As Robert mentioned that it=E2=80=99s the carriers domain so they have= to take
> care of any security issues related to AH on the SRv6 outer IPV6
> transport header.
>
> Also as noted by Robert that all customer traffic is kept in tact and =
> not altered and that no insertion or removal of any EH headers occurs = to
> the inner header customer payload.=C2=A0 So no impact to customers use= of AH
> etc as that is remains unaltered.
>
> Thanks
>
> Gyan
>
>
>
>
> On Fri, May 8, 2020 at 7:06 PM Robert Raszuk <robert@raszuk.net
> <mailto:robe= rt@raszuk.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Philip,
>
>=C2=A0 =C2=A0 =C2=A0Sounds very reasonable.
>
>=C2=A0 =C2=A0 =C2=A0IMO what is needed here is a short spec which would= explicitly call
>=C2=A0 =C2=A0 =C2=A0out the case of using IPv6 as transport layer. Then= it would allow
>=C2=A0 =C2=A0 =C2=A0the transport owner sufficient flexibility (inserti= on, modification,
>=C2=A0 =C2=A0 =C2=A0deletion) into applied by his own ingress new IPv6 = header at any
>=C2=A0 =C2=A0 =C2=A0transit hop he seems required. Ultimate goal is to = deliver carried
>=C2=A0 =C2=A0 =C2=A0payload (here original IPv6 or IPv4 packets) via a = given network the
>=C2=A0 =C2=A0 =C2=A0best quality possible.
>
>=C2=A0 =C2=A0 =C2=A0Thx a lot,
>=C2=A0 =C2=A0 =C2=A0Robert.
>
>
>=C2=A0 =C2=A0 =C2=A0On Sat, May 9, 2020 at 12:42 AM Philip Homburg
>=C2=A0 =C2=A0 =C2=A0<pch-ipv6-ietf-6@u-1.phicoh.com
>=C2=A0 =C2=A0 =C2=A0<mailto:pch-ipv6-ietf-6@u-1.phicoh.com>> wrot= e:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >Now comes the topic of an additi= onal hander mangling even by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nodes which
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >are not intermediate destination= s, yet all within transit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So this is the key point. RFC 8200 ap= plies to all IPv6 packets.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 8200 allows additional header man= gling, then that can happen
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in lots of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other places as well, which is quite = undesirable.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So RFC 8200 has to state that in gene= ral this sort of thing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cannot happen.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Next we can update RFC 8200 with a na= rrowly crafted exception
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tailored to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this use case.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We have two possibilities:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- either RFC 8200 allows mangling by = hops in a routing header.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case we have a problem that n= eeds to be fixed while creating
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an exception
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for segment routing, or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- RFC 8200 does not allow this kind o= f mangling and we need to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0create an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 exception for segment routing= .
>
>
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
>=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list
>=C2=A0 =C2=A0 =C2=A0= ipv6@ietf.org <mailto:ipv6@ietf.org>
>=C2=A0 =C2=A0 =C2=A0Administrative Requests: https://w= ww.ietf.org/mailman/listinfo/ipv6
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
>
> --
>
> Gyan=C2=A0 Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: 301 502-1347
>
> Email: = gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>
>
>
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> -------------------------------------------------------------------- >
--
<= div dir=3D"ltr">

Gyan= =C2=A0 Mishra

Network Engineering & Technology= =C2=A0

Verizon=C2=A0

Silver Spring, MD 20= 904

Phone: 301 502-1347

<= font size=3D"1" color=3D"#000000" face=3D"georgia, serif">Email: gyan.s.mishra@verizon.= com



--000000000000fd550305a52e1e55-- From nobody Sat May 9 01:45:01 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5EC3A08F8 for ; Sat, 9 May 2020 01:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uaVKvaP--r_c for ; Sat, 9 May 2020 01:44:56 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209E83A08CB for ; Sat, 9 May 2020 01:44:55 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 156C680840; Sat, 9 May 2020 10:44:51 +0200 (CEST) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Philip Homburg , ipv6@ietf.org References: From: Fernando Gont Message-ID: <73446d20-8df7-c680-2243-125e6bf3a18a@si6networks.com> Date: Sat, 9 May 2020 05:44:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 08:44:59 -0000 On 8/5/20 19:41, Philip Homburg wrote: >> Now comes the topic of an additional hander mangling even by nodes which >> are not intermediate destinations, yet all within transit network. > > So this is the key point. RFC 8200 applies to all IPv6 packets. So if > RFC 8200 allows additional header mangling, then that can happen in lots of > other places as well, which is quite undesirable. > > So RFC 8200 has to state that in general this sort of thing cannot happen. > Next we can update RFC 8200 with a narrowly crafted exception tailored to > this use case. > > We have two possibilities: > - either RFC 8200 allows mangling by hops in a routing header. In that > case we have a problem that needs to be fixed while creating an exception > for segment routing, or > - RFC 8200 does not allow this kind of mangling and we need to create an > exception for segment routing. I'd say that firstly folks need to make a case why insertion/removal is needed. That's a bit different from the traditional hand-washing approach that have plagged the spring¡s network-programming draft an other related work. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat May 9 01:51:32 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3873A090C for ; Sat, 9 May 2020 01:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1Rm3HUJuHZOk for ; Sat, 9 May 2020 01:51:27 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC303A08CD for ; Sat, 9 May 2020 01:51:27 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D3C148081B; Sat, 9 May 2020 10:51:23 +0200 (CEST) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Gyan Mishra , Robert Raszuk Cc: 6man WG , Erik Kline References: From: Fernando Gont Message-ID: Date: Sat, 9 May 2020 05:50:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 08:51:31 -0000 On 8/5/20 20:27, Gyan Mishra wrote: > > Given that SRv6 PGM draft has left the station awaiting publication Maybe you've not been listening to the loudphones: the IESG is processing an Appeal on that decision: https://mailarchive.ietf.org/arch/msg/ietf/tvhCmlcHt9b2vwrNxR70W9cT4sE/ > I > think the most prudent recourse for 6MAN is to grant the exception for > SRV6 technology to allow insertion and removal on any transit node > within the carriers administrative domain. That would be (yet again) an outright violation of our processes. Things need to happen the other way around: firstly you make the case for an exception to RFC8200, and get RFC8200 formally updated. *Then* you pursue efforts like network-programming. FWIW, I believe modifying RFC8200 to allow eh-insertion/removal would be outside of the 6man charter. I'm CC'ing our AD. Hope he can save everyone's energy this time. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat May 9 01:53:55 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330D43A090D for ; Sat, 9 May 2020 01:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 L368h_Abl9RX for ; Sat, 9 May 2020 01:53:51 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519E33A08CD for ; Sat, 9 May 2020 01:53:51 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 36E668081B; Sat, 9 May 2020 10:53:46 +0200 (CEST) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: "Joel M. Halpern" , Gyan Mishra Cc: 6man WG References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> From: Fernando Gont Message-ID: <2d49cdd9-8308-f70b-36a1-89da4e596e51@si6networks.com> Date: Sat, 9 May 2020 05:53:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 08:53:53 -0000 On 8/5/20 20:33, Joel M. Halpern wrote: > The SRv6 PGM document that was approved does not do arbitrary insertion. >  It does the very specific PSP removal.  I think it inappropriate for > us to say that given that this one piece was allowed, anything and > everything should be allowed. That piece wasn't allowed. Actually, the spring wg shipped the document via a process that was appealed: https://mailarchive.ietf.org/arch/msg/ietf/tvhCmlcHt9b2vwrNxR70W9cT4sE/ Since the Appeal has not yet been addressed, there hasn't been IETF consensus on the network programming draft, and, ultimately, the IESG has not yet approved the document, I don't think anyone can or should consider that any such behavior has been allowed. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat May 9 01:58:23 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F583A0927 for ; Sat, 9 May 2020 01:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rONOcOnG3CZW for ; Sat, 9 May 2020 01:58:12 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B119E3A0911 for ; Sat, 9 May 2020 01:58:12 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 05CEA80831; Sat, 9 May 2020 10:58:09 +0200 (CEST) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Robert Raszuk , "Joel M. Halpern" Cc: 6man WG References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> From: Fernando Gont Message-ID: <4c507442-2a22-ca7c-0e33-8fc7df4b965b@si6networks.com> Date: Sat, 9 May 2020 05:57:58 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 08:58:16 -0000 On 8/5/20 20:39, Robert Raszuk wrote: > And even that much would wait on the resolution of the pending > appeal on > the topic. > > > If we would decouple end to end IPv6 from encapsulated transport IPv6 as > well as allow required flexibility in the transport part there would no > longer be any basis for the appeal. > > Where does it say that we must wait for the result of the appeal if WG > would like to propose the solution which turns the entire appeal in > progress into a moot point ? You might need to re-read the Appeal: https://mailarchive.ietf.org/arch/msg/ietf/tvhCmlcHt9b2vwrNxR70W9cT4sE/ It includes five (5) explicit technical objections, plus three (3) explicit procedural concerns. I have no idea why trying to address one of the five technical concerns, and even more so *after the fact*, would turn the appeal into a moot point. Maybe this is just a confirmation that some folks seem to thing that they can violate our processes at will. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat May 9 03:24:06 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889023A099C for ; Sat, 9 May 2020 03:24:04 -0700 (PDT) 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, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmjUaf-3EYON for ; Sat, 9 May 2020 03:23:59 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6753A099B for ; Sat, 9 May 2020 03:23:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jXMe9-0000I5C; Sat, 9 May 2020 12:23:53 +0200 Message-Id: To: ipv6@ietf.org Cc: Fernando Gont Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <73446d20-8df7-c680-2243-125e6bf3a18a@si6networks.com> In-reply-to: Your message of "Sat, 9 May 2020 05:44:21 -0300 ." <73446d20-8df7-c680-2243-125e6bf3a18a@si6networks.com> Date: Sat, 09 May 2020 12:23:52 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 10:24:05 -0000 >I'd say that firstly folks need to make a case why insertion/removal is >needed. That's a bit different from the traditional hand-washing >approach that have plagged the spring¡s network-programming draft an >other related work. I think we can leave the justification of insertion/removal to the Spring wg. There is no need to discuss in 6man the fine details of how efficient various options are. I think what we should discuss (if there ever comes a draft that tries to update RFC 8200 in this direction) is whether this is safe. How come inserts doesn't cause PMTU problems. How does it interact with authentication headers, and what effect does it have on error ICMPs. And possibly other things that may go wrong. From nobody Sat May 9 03:37:23 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19213A09B3 for ; Sat, 9 May 2020 03:37:19 -0700 (PDT) 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, 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=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITOqENP6N6zN for ; Sat, 9 May 2020 03:37:18 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 A76333A09AC for ; Sat, 9 May 2020 03:37:17 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id e2so3494502eje.13 for ; Sat, 09 May 2020 03:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TP8W2evaoBcz8oeUEZVw06RPRbSi/+QDYtBZtm09fJc=; b=EA9/d5qu3UNDz5fHOtJ3sOL3T0kKnbI+diiM1Kue08XaFaVNlFPIo9/v2Bzzay0i8J o5XFUOkP0qKQhxNSFsAqkIY3RDeKrJZ+k+uK/7SNPXIO/6525LEm/O1MX997k0vjTI/T f4IZ9rzZxkJ9iDcVW1Ew3EJcR59cLqbtj+WqP2TqqVUpYifjQtD2ICUJPL4F0IpLCkKb nVr9YTbITBULLn7vEM7qdReS9TzL0yxY9Sz7MGxZyDAYe0MF18uVwFkGNkAsdtLU0YSK pbNbslZ5xdWUj95esK0zYZR4Jwf7M37TISa+03TAxPu0MF/iYGzVgI6ZND07qlsQgsEb tHcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TP8W2evaoBcz8oeUEZVw06RPRbSi/+QDYtBZtm09fJc=; b=UN2g0cVjsmZxZA2qNUZGEY/RHnkCkcTP1ZjotXXuNlRMdNVDI1JfMYfAcrEc2X6x0W s5m8LinCz1iESI7vYHWYRr8Sw757Aog2NOQnEBWUAsMSJRfCiUeYJVw7pBN4VxottVvQ AD29YFPKQtsbUnw7DZAa3GM9Su/2mzrIa+3jtjAC3UMM8qCnqkX3Q3shGuCRJ/ZEwfK1 B/z2VTeRKtE46yZPB4WyUeAe5pzzfayXcdbpvnitSupp4bUjvuyCq93vIdpTbC3KdyZQ 3eVc1LKrmt4EdZBTVj/qQaBTQR3xmg8LdqsvuStNQZMLUEOnE4iliool4hvKhp441B2i W7JA== X-Gm-Message-State: AGi0Pub0lOA59u/j7to82Fj0s1qIYdbt3Tn6uPlATy9fVYUEwdllWkkd 0mvorAckmowPssRHtHMrNyV/G1VdtMVGwMEbKAM8Mt4lv6I= X-Google-Smtp-Source: APiQypLeop0v34oDEDNqBqSORkBR/wCjB8F7FKr9H2COemSekRuVEatnWjeP/bjeTWVysSh3/JTkSULjcZ2KQdzcqUI= X-Received: by 2002:a17:906:328c:: with SMTP id 12mr5128319ejw.69.1589020635643; Sat, 09 May 2020 03:37:15 -0700 (PDT) MIME-Version: 1.0 References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> In-Reply-To: From: Robert Raszuk Date: Sat, 9 May 2020 12:37:07 +0200 Message-ID: Subject: Role of IETF To: Mark Smith Cc: 6man WG Content-Type: multipart/alternative; boundary="0000000000008756b905a534b20d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 10:37:20 -0000 --0000000000008756b905a534b20d Content-Type: text/plain; charset="UTF-8" /* adjusting the subject */ Hi Mark, It has seemed to me that SPRING have had too much of a "greenfield" > mentality, allowing other existing specs to be taken and casually modified, > rather than proposing modifications only as a last resort, when there is no > other way to make the function work within existing proven mechanisms. > I think you have hit the nail here. There are two roles IETF WGs could endorse: *option 1* Be the strong policer of protocols encoding and its operations invented 20+ years ago. Forbid innovation even if it almost fits with the given protocol definitions as written. *option 2* Create and standardize protocol building blocks (lego bricks), make sure header or attribute types handling is interoperable while in the same time allow transit networks behaviours to be defined using those blocks by the operators itself or by their vendors. Almost all modern data planes can be programmable either by P4 or other languages. - - - Pls observe that option 2 is already happening pretty much outside of IETF meeting rooms and corridors. Who will tell big service/content provider or enterprise that they can not either build a custom chip or program their data plane behaviour in software ? Sure option 2 is very hard for legacy vendors who are not able to support it. Sure it is hard for traditional operators as network operator job may now require solid programming skills. But stating that a WG which just tries to accommodate option 2 "have had too much of a "greenfield" mentality" is just precise illustration where the real problem is. Best, Robert. PS. As an exercise for the reader I have a question. Imagine that I want to standardize a variable length SA and DA to be used as transport addresses in my network. 128 bits to be used within single domain or single enterprise is just pure waist. Note that I am talking about variable length IP address fields but I am actually assuring a fixed exact match locator part. Where would I go with that draft ? Going to 6man and claiming that I was to shrink your 128 dogmatic fields may likely fail. Going to MPLS stating that I would like to extend MPLS with MPLSv2 giving it new life could maybe even work out well ... it is just it would be almost identical to IPv6 format with SRv6 with just few small encoding changes. Go figure ... --0000000000008756b905a534b20d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
/* adjusting the subject */

= Hi Mark,

It has seemed to = me that SPRING have had too much of a "greenfield" mentality, all= owing other existing specs to be taken and casually modified, rather than p= roposing modifications only as a last resort, when there is no other way to= make the function work within existing proven mechanisms.

I think you have hit th= e nail here.=C2=A0

There are two roles IETF WGs co= uld endorse:=C2=A0

*option 1*=C2=A0

=
Be the strong policer of protocols encoding and its operations i= nvented 20+ years ago. Forbid innovation even if it almost fits with the gi= ven protocol definitions as written.=C2=A0

*option= 2*=C2=A0

Create and standardize protocol building= blocks (lego bricks), make sure header or attribute types handling is inte= roperable while in the same time allow transit networks behaviours to be de= fined using those blocks by the operators itself or by their vendors. Almos= t all modern data planes can be programmable either by P4 or other language= s.=C2=A0

- - -=C2=A0

Pls = observe=C2=A0that option 2 is already happening pretty much outside of IETF= meeting rooms and corridors.=C2=A0

Who will tell = big service/content provider or enterprise that they can not either build a= custom chip or program their data plane behaviour in software ?=C2=A0

Sure option 2 is very hard for legacy vendors who are = not able to support it. Sure it is hard for traditional operators as networ= k operator job may now require solid programming skills. But stating that a= WG which just tries to accommodate=C2=A0option 2 "have had too much o= f a "greenfield" mentality" is just precise illustration whe= re the real problem is.=C2=A0

Best,
Robert.

PS.=C2=A0

As an exercise=C2= =A0for the reader I have a question. Imagine that I want to standardize a v= ariable length SA and DA to be used as transport addresses in my network. 1= 28 bits to be used within single=C2=A0domain or single enterprise is just p= ure waist. Note that I am talking about variable length IP address fields b= ut I am actually assuring a fixed exact match locator part.=C2=A0

Where would I go with that draft ?=C2=A0

Going to 6man and claiming that I was to shrink your 128 dogmatic fi= elds may likely fail.=C2=A0

Going to MPLS stating = that I would like to extend MPLS with MPLSv2 giving it new life could maybe= even work out well ... it is just it would be almost identical to IPv6 for= mat with SRv6 with just few small encoding changes.=C2=A0

Go figure ...=C2=A0
=C2=A0
--0000000000008756b905a534b20d-- From nobody Sat May 9 04:23:39 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B791E3A08C4 for ; Sat, 9 May 2020 04:23:36 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 3fvfk3KNyCkn for ; Sat, 9 May 2020 04:23:32 -0700 (PDT) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87653A098B for ; Sat, 9 May 2020 04:23:31 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2054.outbound.protection.outlook.com [104.47.12.54]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-23-rYVuEeFYND6KyYhr22z0bw-1; Sat, 09 May 2020 12:23:24 +0100 X-MC-Unique: rYVuEeFYND6KyYhr22z0bw-1 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VI1PR03MB3741.eurprd03.prod.outlook.com (2603:10a6:803:36::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.33; Sat, 9 May 2020 11:23:21 +0000 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::ed68:9303:79e0:cc49]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::ed68:9303:79e0:cc49%4]) with mapi id 15.20.2979.033; Sat, 9 May 2020 11:23:21 +0000 From: Andrew Alston To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , Gyan Mishra CC: 6man WG Subject: Re: whether to grant exception for SRV6 (Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03) Thread-Topic: whether to grant exception for SRV6 (Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03) Thread-Index: AQHWJZnNlIwnKCbmmk2KVPHn5iS2tqifnHhG Date: Sat, 9 May 2020 11:23:21 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [105.62.108.198] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f8defe91-c10e-413e-77bf-08d7f40b61aa x-ms-traffictypediagnostic: VI1PR03MB3741: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-forefront-prvs: 03982FDC1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: taEgIZ+AAx2TYLb2C8xKJnT2HByvaPS3FvO4KUZivXYjApBSuspil31uTQnPxEkzBxcwaYBPXS9kFemf29z2CQy+8SmpbFZQpRQUxQVM1rBliRTeUBcDyS+qcUGOEJXuKmEoOx/kxtmLjQD7or49ODbUZJsS1Y7V2VECrxIGKB2CXju1H5UydX1vGfMEPsbf43zpJhPQur6JYmFhnW2IyT2t4eW6rxC9d8W+dgUb3PCP8oviZroUDkGGVLor88ex17Xn2frsDya3dWiNZauhSsrZsTbGqvTqD4a32lbT3pc+iNT/lSx0YDxr6RohBwNkLf/aZgv44kbPsejGIlrAqVoelTQyRTdvxvCZWwESoQJP7anJflf1ACfXUH9HeRJvlirJnuIZ0vQGh35trmwMT8QXHRE6ru1V83SVG+o9BwDnlTVbeWqTuW6luQsh4UNyLHeHGfAgjiqWi4xO+825v3OPQQjUFhd/6XypXagPIG8w/vuhLqMO0KWes/4nwYrr02UCZdsiNNtb0ijs6m2L3ghD8Gob+ne+zrpMFj+jlMepCxieKSJukLtEwU01AH6zQETqqBhLCXKtGvQ0tcucFyodAWiRBkGlkkRoRG/dAfU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB5056.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(376002)(396003)(136003)(346002)(33430700001)(8676002)(52536014)(45080400002)(4326008)(55016002)(8936002)(9686003)(4744005)(64756008)(66446008)(55236004)(15650500001)(186003)(5660300002)(26005)(86362001)(2906002)(71200400001)(316002)(110136005)(66556008)(478600001)(166002)(66476007)(53546011)(6506007)(33440700001)(7696005)(33656002)(66946007)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: e9SjcJfvf95O4eButFgkK6q7EscVAnhek+uZsOQEOCtf1CzgjVSdn6X64jmqi0Fedfnf31QPNY4jYMwUpAXkX59Nk70gDv3f9MepZU9Vi/c//SCWQ1pr3KOjQXLyZYPsZ2g47oBqAUbHPUVBBwQn5EX1stPsFUyIXuTtlsgshz6vuPhbDp+sOSDWw09Uq4JZ/3Gxiz9ffpIVP6FOh9ZdqcQS8gkNTAOi8Uzx9ydPOtiyYi2w1EC6ooT3huVmelh1RMLV48DJWBRIqKJjHW4xEGHRWFndXIVhmA4IuLPuV29OHEAIC1pAsSiPFcgyMcfvSLT1EVRSnl5O7NeIiCit7fW/AfAw/NtTuOD0NNzK3OPQcBLfXKP87lqsR7HQdz0NvlE+YihuI648qNm+birif20xepWJB2ga54LhXPoJziadDB08acFzbbhm64uglEKFWiCJATGUIPORHXfsx1Dj6/2+Xk3SSwkDOS/B3eCX5si4qyKbJQrxryiMdcliCyfd x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-Network-Message-Id: f8defe91-c10e-413e-77bf-08d7f40b61aa X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2020 11:23:21.4395 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MlwAtylR0AvCs6Lt2JGEo2+e8Rkv8sXE8JCN/oPTXBw9IG9At6q/gnXMHZM0McFtRcqUfiwrNxKhOGgkQmJ0JL1oA9QwgvdWDI9a0tJez+s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB3741 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Type: multipart/alternative; boundary="_000_VI1PR03MB50567649859FD93238509DFAEEA30VI1PR03MB5056eurp_" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 11:23:37 -0000 --_000_VI1PR03MB50567649859FD93238509DFAEEA30VI1PR03MB5056eurp_ Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: quoted-printable Get Outlook for iOS ________________________________ From: ipv6 on behalf of =1B$B?@L@C#:H=1B(B Sent: Saturday, May 9, 2020 03:35 To: Gyan Mishra Cc: 6man WG Subject: whether to grant exception for SRV6 (Re: some feedback on feedback= on draft-bonica-6man-ext-hdr-update-03) At Fri, 8 May 2020 19:27:53 -0400, Gyan Mishra > wrote: > Given that SRv6 PGM draft has left the station awaiting publication I thi= nk I would hardly say it has left the station awaiting publication - the docum= ent is under appeal on a multitude of points - both technical related to ps= p and a raft of process issues. Let us await the outcome of the appeal before declaring the document a done= deal. Andrew --_000_VI1PR03MB50567649859FD93238509DFAEEA30VI1PR03MB5056eurp_ Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: quoted-printable

From: ipv6 <ipv6-bounces@ietf.org> on behalf of =1B$B?@L@C#:H=1B= (B <jinmei@wide.ad.jp>
Sent: Saturday, May 9, 2020 03:35
To: Gyan Mishra
Cc: 6man WG
Subject: whether to grant exception for SRV6 (Re: some feedback on f= eedback on draft-bonica-6man-ext-hdr-update-03)
 
At Fri, 8 May 2020 19:27:53 -0400,
Gyan Mishra <hayabusagsm@gmail.= com> wrote:

> Given that SRv6 PGM draft has left the station awaiting publication I = think

I would hardly say it has left the station awaiting public= ation - the document is under appeal on a multitude of points - both techni= cal related to psp and a raft of process issues.

Let us await the outcome of the appeal before declaring th= e document a done deal.

Andrew 
--_000_VI1PR03MB50567649859FD93238509DFAEEA30VI1PR03MB5056eurp_-- From nobody Sat May 9 04:24:46 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9700D3A08C4 for ; Sat, 9 May 2020 04:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pzFlYDXe3oNY for ; Sat, 9 May 2020 04:24:43 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0442E3A098B for ; Sat, 9 May 2020 04:24:28 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0D1B18087E; Sat, 9 May 2020 13:24:25 +0200 (CEST) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Philip Homburg , ipv6@ietf.org References: <73446d20-8df7-c680-2243-125e6bf3a18a@si6networks.com> From: Fernando Gont Message-ID: <9cedfa8b-b061-cee0-92ca-bd3f15f2d744@si6networks.com> Date: Sat, 9 May 2020 08:21:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 11:24:45 -0000 On 9/5/20 07:23, Philip Homburg wrote: >> I'd say that firstly folks need to make a case why insertion/removal is >> needed. That's a bit different from the traditional hand-washing >> approach that have plagged the spring¡s network-programming draft an >> other related work. > > I think we can leave the justification of insertion/removal to the Spring > wg. There is no need to discuss in 6man the fine details of how efficient > various options are. > > I think what we should discuss (if there ever comes a draft that tries to > update RFC 8200 in this direction) is whether this is safe. How come inserts > doesn't cause PMTU problems. How does it interact with authentication headers, > and what effect does it have on error ICMPs. And possibly other things that > may go wrong. That's indeed what I meant to say. Thanks for summarizing it! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat May 9 04:26:53 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1233A098B for ; Sat, 9 May 2020 04:26:52 -0700 (PDT) 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, 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, 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 N_dJY5LuAipQ for ; Sat, 9 May 2020 04:26:50 -0700 (PDT) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [146.101.78.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303633A08C4 for ; Sat, 9 May 2020 04:26:49 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2056.outbound.protection.outlook.com [104.47.12.56]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-275-xJrJhwhVP7CwreUrAPwHzg-1; Sat, 09 May 2020 12:26:45 +0100 X-MC-Unique: xJrJhwhVP7CwreUrAPwHzg-1 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VI1PR03MB3741.eurprd03.prod.outlook.com (2603:10a6:803:36::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.33; Sat, 9 May 2020 11:26:45 +0000 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::ed68:9303:79e0:cc49]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::ed68:9303:79e0:cc49%4]) with mapi id 15.20.2979.033; Sat, 9 May 2020 11:26:44 +0000 From: Andrew Alston To: Robert Raszuk , "Joel M. Halpern" CC: 6man WG Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 Thread-Topic: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 Thread-Index: AQHWI0N2oghY3/njjUy91Jf/oCcBs6iaXE+AgAEndQCAAAbXgIAC2BEAgAAKbYCAABKnSoAAEzgAgAADtrqAACAxAIAAFozTgAAGoACAAAYFgIAAAXmAgAAB5oCAAMT0fA== Date: Sat, 9 May 2020 11:26:44 +0000 Message-ID: References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [105.62.108.198] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b8fb7be0-c777-4d61-39f2-08d7f40bdada x-ms-traffictypediagnostic: VI1PR03MB3741: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03982FDC1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /R9Y+Epj3bF7hK4CVTjbNxSGXHtJM498qrs/Ez6Djrs5wrd6RinChpcAJUUYO0lp7FP/HXCTJYNgKXzz4BBg+eDusqqsW5TxYIWfR9bskX1DjFJjrLrSaP7maiNjDk/6S51qzWZNnSG8juEqYg2ToDMhxYzUp0okUprH7TX7I+vsnqRWuVn5we7jlJ/66qu8BvqZTk00BUByCB7dAB/5W+zpjyWZtgwTg2i2/O+ZjlFL8UhFk1/RHw6yEjTC0W5ipaa2cDtZBIE/dyurSQXv3UB4Gfpw6B6WMvxNjsOJq7zQo3TJO7XI5WgOk5Je0EQxaCHVEW8ruCI7cWphtecE5Z3kevaLRgTjzrPue1/1ji/F3eKl00+eRpDeoGsXXE0QGqwVNQpOrR8xDrfiKOHP9fOD/6plyrKeUj8vYXVlIL8yQmWKkD2WmEdUSVBexecf+2RsRbmb4FRZAgGNxHgUpOVUMckmmGf9Vg8HgVP9JGQcrNNIRZPhYjR8fKNasZsqLfUnIKAme3XGkJtQGlPDPTIruq45a8B09NPqBI2ZlPVyAzLSrnsTORGezrUaOpEdjLzGSvtR2XOozhqlvCXlnVjZAL7ICYRQ0vglzlklvtg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB5056.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(396003)(376002)(39860400002)(366004)(33430700001)(86362001)(110136005)(316002)(71200400001)(2906002)(15650500001)(64756008)(66446008)(55236004)(26005)(186003)(5660300002)(7696005)(33440700001)(33656002)(76116006)(66946007)(166002)(478600001)(66556008)(53546011)(6506007)(66476007)(45080400002)(8676002)(52536014)(9686003)(4744005)(55016002)(4326008)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: kO/UzTRDDW/ua2hVTGEigg0L+djLI5x5XrvMEQ7UCcZMvsXSf2akqQAq2SkrH6J2cAbE6Uwm/BGyYH0DopZXc1ghXesxY8QEhWU8XllQ/1gc8FfcpNV3NQAZ26oP0EXXI3eaP8zoCIdQnyYdjLIagoNiGL13c6nhePUf/RZZopn03AW/kGc5foahJZv+O/y2W8LbK1dvzEWOkUjND7gtRhVN1H2G+GSKyTIVCcscPexBdNYEtH4XGdlUfrm90Cf+NbZz+Z5xUTGn93RzPECzfLjqf0tccxTAt+kMxeAoE0ND/7IXlcpMpocRo9AyuqHLRBREGHxQ60DFW25FusCzf1ARmfKAR/hYz82GhZHf0XHuQmLU4aYobcvmr9NJlyTIkopjaRJUwrucheiI0vZFD9qAuOphRHqmq+UKxe/eLs7JUSScSvbNWPnk19KKvfdUscsw6HmAx88h4PipsKTNPgcXa/0g8on6uYA+HCVen5/twYPlTx0auPfg5fVkIAf4 x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8fb7be0-c777-4d61-39f2-08d7f40bdada X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2020 11:26:44.8217 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CoaaR0XopsCKW33+OSUM2bXSTysTE5/4E8Q2DOrU9A3XWQtzDi6uwrEJU96tuAa+IACIsWOYzwrrraD94fqHGfZ8l19XHVYvcsUOgydhZII= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB3741 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Type: multipart/alternative; boundary="_000_VI1PR03MB505694B2DE242E317D857C9DEEA30VI1PR03MB5056eurp_" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 11:26:52 -0000 --_000_VI1PR03MB505694B2DE242E317D857C9DEEA30VI1PR03MB5056eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Get Outlook for iOS ________________________________ From: ipv6 on behalf of Robert Raszuk Sent: Saturday, May 9, 2020 02:40 To: Joel M. Halpern Cc: 6man WG Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-= 03 And even that much would wait on the resolution of the pending appeal on the topic. If we would decouple end to end IPv6 from encapsulated transport IPv6 as we= ll as allow required flexibility in the transport part there would no longe= r be any basis for the appeal. Where does it say that we must wait for the result of the appeal if WG woul= d like to propose the solution which turns the entire appeal in progress in= to a moot point ? Robert I suggest you read the appeal - the psp issue is not the only issue = in the appeal - so while whatever is done here may resolve that issue - it = is hardly the only issue and resolving this would not render the entire app= eal moot - it would resolve that one point Andrew --_000_VI1PR03MB505694B2DE242E317D857C9DEEA30VI1PR03MB5056eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

From: ipv6 <ipv6-bounces@ietf.org> on behalf of Robert Raszuk &l= t;robert@raszuk.net>
Sent: Saturday, May 9, 2020 02:40
To: Joel M. Halpern
Cc: 6man WG
Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-= update-03
 
 
And even that much would wait on the resolution of the pending appeal on the topic.

If we would decouple end to end IPv6 from encapsulated transport IP= v6 as well as allow required flexibility in the transport part there would = no longer be any basis for the appeal. 

Where does it say that we must wait for the result of the appeal if= WG would like to propose the solution which turns the entire appeal in pro= gress into a moot point ? 

Robert I suggest you read the appeal - the psp issue is no= t the only issue in the appeal - so while whatever is done here may resolve= that issue - it is hardly the only issue and resolving this would not rend= er the entire appeal moot - it would resolve that one point

Andrew 

--_000_VI1PR03MB505694B2DE242E317D857C9DEEA30VI1PR03MB5056eurp_-- From nobody Sat May 9 04:29:26 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE483A098B for ; Sat, 9 May 2020 04:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2zQGfblIqAzp for ; Sat, 9 May 2020 04:29:23 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D95A3A0954 for ; Sat, 9 May 2020 04:29:23 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 107848087E; Sat, 9 May 2020 13:29:19 +0200 (CEST) Subject: Re: Role of IETF To: Robert Raszuk , Mark Smith Cc: 6man WG References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> From: Fernando Gont Message-ID: <6f33e812-7482-0cdf-0e48-0264c8c334a7@si6networks.com> Date: Sat, 9 May 2020 08:29:12 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 11:29:25 -0000 On 9/5/20 07:37, Robert Raszuk wrote: > /* adjusting the subject */ > > Hi Mark, > > It has seemed to me that SPRING have had too much of a "greenfield" > mentality, allowing other existing specs to be taken and casually > modified, rather than proposing modifications only as a last resort, > when there is no other way to make the function work within existing > proven mechanisms. > > > I think you have hit the nail here. > > There are two roles IETF WGs could endorse: There's one role that WGs MUST endorse: RFC2026. If you feel otherwise, feel free to publish a draft that updates RFC2026, have it gain IETF-wide consensus, and get the IETF to do whatever it feels it should be doing. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat May 9 04:36:00 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5156A3A09CA for ; Sat, 9 May 2020 04:35:58 -0700 (PDT) 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_H4=0.001, RCVD_IN_MSPIKE_WL=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 0HzLMTLROHT9 for ; Sat, 9 May 2020 04:35:56 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176D03A0A07 for <6man@ietf.org>; Sat, 9 May 2020 04:35:56 -0700 (PDT) Received: from lhreml702-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4205D98D3E1EA65ECEBC; Sat, 9 May 2020 12:35:52 +0100 (IST) Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Sat, 9 May 2020 12:35:52 +0100 Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Sat, 9 May 2020 12:35:51 +0100 Received: from DGGEML509-MBS.china.huawei.com ([169.254.4.143]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0487.000; Sat, 9 May 2020 19:35:46 +0800 From: "Chengli (Cheng Li)" To: "Voyer, Daniel" , "Joel M. Halpern" , Robert Raszuk CC: 6man <6man@ietf.org>, "Darren Dukes (ddukes)" Subject: RE: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AQHWI6M6CwpEzhq07ESsLUQJlNiRYaicUCYAgAALrACAARn/AIAABP0AgAA9jICAABnngIAB0GVg Date: Sat, 9 May 2020 11:35:46 +0000 Message-ID: References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> <5F668736-023A-4E3E-B55B-B952E0B68BB9@bell.ca> In-Reply-To: <5F668736-023A-4E3E-B55B-B952E0B68BB9@bell.ca> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.229] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 11:35:59 -0000 V2VsbCwgSSBkb24ndCBrbm93IG90aGVyIHZlbmRvcnMsIGJ1dCB3ZSBtYXkgbm90IGRvIHRoYXQu IA0KDQpUaW1lIGFuZCByZXNvdXJjZXMgYXJlIHJlYWxseSBpbXBvcnRhbnQsIGFuZCB0aGV5IHNo b3VsZCBiZSB1c2VkIGZvciBkZXZlbG9waW5nIHdoYXQgd2Ugd2FudCB0byBwcm92aWRlIGZvciBv dXIgY3VzdG9tZXJzLg0KDQpBbHNvLCBJIHdpbGwgYmUgZXhjaXRlZCBmb3Igc3VyZSBpZiBteSBk cmFmdCBpcyBpbXBsZW1lbnRlZCBhbmQgZGVtb2VkIGluIGludGVyLW9wIHRlc3QsIHRoYXQgbWVh bnMgYSBsb3QuDQoNCkJ1dCBhbnl3YXksIGZhY3QgaXMgZmFjdCwgb3BpbmlvbiBpcyBvcGluaW9u LiBXZSBjYW4gbGV0IHRoZW0gYmUgdGhlcmUgdG9nZXRoZXIuIA0KDQpXZSBrbm93IHRoZSBmYWN0 LCBhbmQgd2UgaGF2ZSBvdXIgb3BpbmlvbnMsIHRoYXQgaXMgaXQuDQoNCkJlc3QsDQpDaGVuZw0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVm95ZXIsIERhbmllbA0KU2VudDogRnJpZGF5 LCBNYXkgOCwgMjAyMCAxMTo0NiBQTQ0KVG86IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxw ZXJuLmNvbT47IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0Pg0KQ2M6IDZtYW4gPDZt YW5AaWV0Zi5vcmc+OyBEYXJyZW4gRHVrZXMgKGRkdWtlcykgPGRkdWtlcz00MGNpc2NvLmNvbUBk bWFyYy5pZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBSb3V0aW5nIEhlYWRlciBJbnNlcnRpb24NCg0K DQoNCu+7v09uIDIwMjAtMDUtMDgsIDEwOjEzIEFNLCAiaXB2NiBvbiBiZWhhbGYgb2YgSm9lbCBN LiBIYWxwZXJuIiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqbWhAam9lbGhh bHBlcm4uY29tPiB3cm90ZToNCg0KICAgIE5vIFJvYmVydCwgYSB2ZW5kb3Igc2VuZGluZyBzb21l dGhpbmcgdG8gYW4gaW50ZXJvcGVyYWJpbGl0eSB0ZXN0IGRvZXMgDQogICAgbm90IHByb3ZlIHRo YXQgdGhlIGZlYXR1cmUgaXMgdXNlZnVsIHRvIGFueW9uZS4gIA0KDQpEVjpBcyBpZiB2ZW5kb3Jz IHdpbGwgdGFrZSB0aW1lICYgcmVzb3VyY2VzICgkJCQpIHRvIGRldmVsb3AgZmVhdHVyZXMgdGhh dCBtaWdodCBub3QgYmUgdXNlZnVsIHRvIGFueW9uZSBhbmQgdGhlbiBnbyB0byB0aGUgdHJvdWJs ZSBvZiBtYWtpbmcgcHVibGljIGludGVyb3AgcGFwZXIgPz8hIQ0KDQoNCkRhbg0KDQogICAgT24g NS84LzIwMjAgNjozMyBBTSwgUm9iZXJ0IFJhc3p1ayB3cm90ZToNCiAgICA+IA0KICAgID4gSGV5 IEFuZHJldywNCiAgICA+IA0KICAgID4gSSBkb24ndCB0aGluayB0aGUgcG9pbnQgaXMgb24gd2hh dCBvbmUgdmVuZG9yIGRlc2lyZXMgb3IgbGlrZXMuIFRoZSANCiAgICA+IHBvaW50IGlzIHRoYXQg dGhleSBpbnRlcm5hbGx5IGNvbW1pdHRlZCBkZXZlbG9wbWVudCByZXNvdXJjZXMgdG8gZGVsaXZl ciANCiAgICA+IHRoaXMgZnVuY3Rpb25hbGl0eS4gVGhleSBhbHNvIGFza2VkIG9uZSBvZiB0aGVp ciB0b3AgdGFsZW50ZWQgDQogICAgPiBUTUUgS3J6eXNpZWsgdG8gZ28gYW5kIGRlbW8gaXQuIEl0 IGNhcnJpZXMgYSBtZXNzYWdlLiBBbmQgYWxsIFphZmFyIGFuZCANCiAgICA+IG90aGVycyBkaWQg d2FzIGp1c3Qgc2hhcmluZyB0aGF0IG1lc3NhZ2UuDQogICAgPiANCiAgICA+IEl0IHJlYWxseSBk b2VzIG5vdCBtYXR0ZXIgdGhhdCBtdWNoIFJvbiBoaW1zZWxmIG9yIG9uIGJlaGFsZiBvZiBoaXMg DQogICAgPiBjb21wYW55IGNhbiBqdW1wIG9uIHRoZSBsaXN0cyBzdGF0aW5nIHRoYXQgaGUgZG9l cyBub3QgbGlrZSBpdC4gRXZlbiBpZiANCiAgICA+IEp1bmlwZXIgbWFya2V0aW5nIHdpbGwgbm90 IHB1c2ggaXQgLSBldmVuIGlmIHRoZXkgZGV2ZWxvcCBuZXh0IGNhcnRvb24gDQogICAgPiBtb2Nr aW5nIGl0IC0gdGhleSB3aWxsIHN0aWxsIGxpa2VseSBjaGVjayBtYXJrIHN1cHBvcnQgdGFnIG9u IHRoZSBSRlBzLg0KICAgID4gDQogICAgPiAqQWxsIHRoYXQgcHJvdmVzIHRoYXQgU1JIIGluc2Vy dGlvbiBpcyBhIHVzZWZ1bCBmZWF0dXJlIHRvIGN1c3RvbWVycy4qIA0KICAgID4gQW5kIHRoYXQn cyBhbGwgd2hhdCBtYXR0ZXJzIHRvIHNvbWUgSUVURiBkZWNpc2lvbnMgYXMgcGFydCBvZiB0aGF0 IGlzIA0KICAgID4gY29tbXVuaXR5IG5lZWRzIGFuZCBzdXBwb3J0IGZvciBleHRlbnNpb25zIHVu ZGVyIHN0YW5kYXJkaXphdGlvbi4NCiAgICA+IA0KICAgID4gQmVzdCwNCiAgICA+IFJvYmVydC4N CiAgICA+IA0KICAgID4gDQogICAgPiBPbiBGcmksIE1heSA4LCAyMDIwIGF0IDEyOjE2IFBNIEFu ZHJldyBBbHN0b24gDQogICAgPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSANCiAg ICA+IDxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+IHdyb3RlOg0KICAg ID4gDQogICAgPiAgICAgSSBkbyBmaW5kIGl0IGtpbmRhIGJpemFycmUgdGhhdCBvbmUgdmVuZG9y IG9yIGFuIGluZGl2aWR1YWwgd291bGQNCiAgICA+ICAgICBqdW1wIHRvIGEgY29uY2x1c2lvbiBh bmQgbWFrZSBzdGF0ZW1lbnRzIGFib3V0IHdoYXQgYW5vdGhlciBvbmUNCiAgICA+ICAgICBkZXNp cmVzIOKAkyBzdXJlbHkgaXQgaXMgdXAgdG8gdGhlIHZlbmRvciB0aGF0IGRlc2lyZXMgc29tZXRo aW5nIHRvDQogICAgPiAgICAgcHVibGljbHkgc3RhdGUgc28gYW5kIG5vdCBmb3Igc29tZW9uZSBl bHNlIHRvIG1ha2Ugc3RhdGVtZW50cyBvbg0KICAgID4gICAgIHRoZWlyIGJlaGFsZj9fX19fDQog ICAgPiANCiAgICA+ICAgICBfXyBfXw0KICAgID4gDQogICAgPiAgICAgSSBtZWFuIOKAkyBsZXTi gJlzIGJlIGNsZWFyIOKAkyBJIGhhdmUgd3JpdHRlbiBhIHBhcnRpYWwgU1J2NiAvIFNSdjYtTlAN CiAgICA+ICAgICBpbXBsZW1lbnRhdGlvbiBpbnRvIG91ciBEUERLIGxhYiB0ZXN0aW5nIHN0YWNr IOKAkyBJIGRpZCBpdCB0byB2ZXJpZnkNCiAgICA+ICAgICBjZXJ0YWluIHRoaW5ncyDigJMgdGhl IG9ubHkgdGhpbmcgaXQgZnVydGhlciBjb252aW5jZWQgbWUgIG9mIGlzIHRoYXQNCiAgICA+ICAg ICBJIHdpbGwgbmV2ZXIgcnVuIHRoaXMgaW4gcHJvZHVjdGlvbiDigJMgaW4gYSBtaWxsaW9uIHll YXJzIOKAkyBhbmQgSeKAmWQNCiAgICA+ICAgICBiZSByYXRoZXIgY29uY2VybmVkIGlmIHNvbWVv bmUgd2VudCBvdXQgdGhlcmUgYW5kIHNhaWQgb24gdGhlIGJhc2lzDQogICAgPiAgICAgb2YgdGhl IGZhY3QgdGhhdCBJIGNob3NlIHRvIHRlc3Qgc29tZXRoaW5nIOKAkyBJIHN1ZGRlbmx5IHN1cHBv cnRlZCBvcg0KICAgID4gICAgIGxpa2VkIGl0LiAgV2hhdCB0aGF04oCZcyBlZmZlY3RpdmVseSBz YXlpbmcgaXMg4oCTIHRvIHRlc3Qgc29tZXRoaW5nIGlzDQogICAgPiAgICAgdG8gc3VwcG9ydCBp dCDigJMgdGhhdOKAmXMgbm90IHRoZSBjYXNlLiAgSXTigJlzIHNpbWlsYXIgdG8gdGhlIGxpbmUg dGhhdA0KICAgID4gICAgIEkgd2FzIGdpdmVuIHRoYXQgYmVjYXVzZSBJIHNpZ25lZCBhIGJsdWUg c2hlZXQgaW4gU2luZ2Fwb3JlIGFuZA0KICAgID4gICAgIGRpZG7igJl0IHN0YW5kIHVwIGF0IHRo ZSBtaWNyb3Bob25lIGFuZCBwdWJsaWNhbGx5IG9iamVjdCB0byBzb21ldGhpbmcNCiAgICA+ICAg ICBhdCB0aGUgdGltZSDigJMgc29tZSBob3cgbXkgc2lnbmF0dXJlIG9uIHRoZSBibHVlIHNoZWV0 IGluZGljYXRlZCBteQ0KICAgID4gICAgIGFjY2VwdGFuY2UgYW5kIHN1cHBvcnQgb2YgdGhlIGlz c3VlIGluIHF1ZXN0aW9uLiBfX19fDQogICAgPiANCiAgICA+ICAgICBfXyBfXw0KICAgID4gDQog ICAgPiAgICAgKFRvIHF1b3RlIHRoYXQpX19fXw0KICAgID4gDQogICAgPiAgICAgX18gX18NCiAg ICA+IA0KICAgID4gICAgIC9QQzI6IFRoZSBjb21tZW50IHN0YXJ0ZWQgYmVjYXVzZSBpbiB0aGUg ZHJhZnQgd2UgaGFkIGFuIGV4YW1wbGUNCiAgICA+ICAgICB0aGF0IHdhcyBhc3NpZ25pbmcgQTox OjovMzIgYXMgbG9vcGJhY2sgaW50ZXJmYWNlIGZvciBhIHJvdXRlci4gVGhpcw0KICAgID4gICAg IGlzIHdyb25nIChwcmVmaXggbGVuZ3RoLCBkb2N1bWVudGF0aW9uIHByZWZpeCwpLi8vX19fXy8N CiAgICA+IA0KICAgID4gICAgIC9UaGlzIHdhcyBmaXhlZCBpbiByZXZpc2lvbiAyIG9mIHRoZSBX RyBkcmFmdCwgcHVibGlzaGVkIGluDQogICAgPiAgICAgU2VwdGVtYmVyIDE5XnRoIDIwMTkuIFRo ZSBjbG9zdXJlIG9mIHRoaXMgY29tbWVudCB3YXMgcHJlc2VudGVkIGJ5DQogICAgPiAgICAgbWUg cGVyc29uYWxseSBpbiBJRVRGIFNpbmdhcG9yZS4gUGxlYXNlIHJlZmVyIHRvIHRoZSBzbGlkZXMu IEluDQogICAgPiAgICAgU2luZ2Fwb3JlIHlvdSB3ZXJlIHByZXNlbnQgKHNpZ25lZCBibHVlIHNo ZWV0KSBhbmQgZGlkIG5vdCBoYWQgYW55DQogICAgPiAgICAgY29tbWVudCBhYm91dCBzdWNoIGNs b3N1cmUuLy9fX19fLw0KICAgID4gDQogICAgPiAgICAgLy8vX19fXy8NCiAgICA+IA0KICAgID4g ICAgIC8vL19fX18vDQogICAgPiANCiAgICA+ICAgICAvVGhpcyBpcyBpbnRlcmVzdGluZyDigJMg c28gZmlyc3RseSDigJMgbGV0IG1lIHN0YXRlIHRoYXQgYmVjYXVzZSBJIHdhcw0KICAgID4gICAg IHByZXNlbnQgaW4gYSBtZWV0aW5nIGFuZCBzaWduZWQgYSBibHVlIHNoZWV0IHRvIHNheSBJIHdh cyB0aGVyZSDigJMgaW4NCiAgICA+ICAgICBubyB3YXkgaW5kaWNhdGVzIHRoYXQgSSBmb3JnbyB0 aGUgcmlnaHQgdG8gb2JqZWN0IGFmdGVyIHRoZSBtZWV0aW5nDQogICAgPiAgICAg4oCTIGFuZCBs YXN0IEkgY2hlY2tlZCwgc2lnbmF0dXJlcyBvbiBhIGJsdWUgc2hlZXQgYXJlIHRoZXJlIHRvIHRy YWNrDQogICAgPiAgICAgYXR0ZW5kYW5jZSwgbm90IHRvIHRyYWNrIGNvbnNlbnN1cy5fX19fLw0K ICAgID4gDQogICAgPiAgICAgL19fIF9fLw0KICAgID4gDQogICAgPiAgICAgX18gX18NCiAgICA+ IA0KICAgID4gICAgIFNvIOKAkyBjYW4gSSBtYWtlIGEgaHVtYmxlIHJlcXVlc3QgdGhhdCB3ZSBs ZXQgcGVvcGxlIHNwZWFrIGZvcg0KICAgID4gICAgIHRoZW1zZWx2ZXMgYWJvdXQgd2hhdCB0aGV5 IGFjdGl2ZWx5IHN1cHBvcnQgYW5kIHdhbnQgcmF0aGVyIHRoYW4NCiAgICA+ICAgICB0cnlpbmcg dG8gc3BlYWsgZm9yIG90aGVycyB0byBib2xzdGVyIG91ciBjYXNlPyAgQmVjYXVzZSBpZiB0aGUg Y2FzZQ0KICAgID4gICAgIGlzIHNvIHdlYWsgdGhhdCB3ZSBuZWVkIHRvIG1ha2UgY2xhaW1zIG9u IGJlaGFsZiBvZiBvdGhlcnMg4oCTIHRoZW4NCiAgICA+ICAgICB0aGVyZSBpcyBubyBjYXNlIGF0 IGFsbC5fX19fDQogICAgPiANCiAgICA+ICAgICBfXyBfXw0KICAgID4gDQogICAgPiAgICAgVGhh bmtzX19fXw0KICAgID4gDQogICAgPiAgICAgX18gX18NCiAgICA+IA0KICAgID4gICAgIEFuZHJl dw0KICAgID4gDQogICAgPiANCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiBJRVRGIElQdjYgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QNCiAgICA+IGlwdjZAaWV0Zi5vcmcNCiAgICA+IEFkbWlu aXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwdjYNCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiANCg0KICAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAg SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQogICAgaXB2NkBpZXRmLm9yZw0K ICAgIEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwdjYNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KICAgIEV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxp bmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZl YyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBJUHY2 IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3JnDQpBZG1pbmlzdHJhdGl2 ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0K From nobody Sat May 9 04:40:56 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1C23A0A0A for ; Sat, 9 May 2020 04:40:54 -0700 (PDT) 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, 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=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Qphonub-FM6 for ; Sat, 9 May 2020 04:40:53 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8373A3A09CA for ; Sat, 9 May 2020 04:40:38 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id l3so3560614edq.13 for ; Sat, 09 May 2020 04:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bQCbuL0wIO5jGd1wMY/wh4C0gK7bCNHnW2c8TWiHYaY=; b=TRt6g0ldjV73+nTP+gtDy4V2Hvia5pMW8V1Z6rJE0eW5Lf3dZIFYAhX2mVIzKHi1H1 awiPu+Z1cOxArC3yuVirBsvIWrYImml0ljYxtkvZyhPWvtijw8dG/qrBgWVzk3x/+EJm eCp1uj50hgqW6mCStoqudEq08w628RzyTni85OOccihOZVGYbmiiyWXfjjCpxmziur9X DxREY5yxWVJa9RiakgEjzuDI9f71V1yocQvkM+GfaJzZmJB6waAuvgon3niy2aYSltkh x4+UfFSG2klwe2UWhb32l73P904EHJhQ1tjleUcDsn+e2EMAUV4B+aAaRtmJJskvzypp GqNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bQCbuL0wIO5jGd1wMY/wh4C0gK7bCNHnW2c8TWiHYaY=; b=KukEnx/VfgybYygXnnM3uMt75E8nql6S5Xfpa94TiAn+sWVcDWT4WQncLIoVd7ogre en6OtsJemTjfwiwP/FN47Q+7t/mKVlGKiiSFTcQpuA7wRqdOCl8wD5+KcyQGVqfFGZtv 0K0/vRdxf9miYZDHBHw+g6WHoY8NAQ6XjHyQViLJJN5igYgqWKv7NVI1a0PVRF146uky fGWsQ2vqUA/qNzs50UDdnTwHXPmqIsrTcKl6xuKLz++Sn0h2BLbvS9OCpUIpLQ4xjhN/ ua6Zeg//czmMcAPVtMl1BqgHIbNY1WHqr9ZoLfE1KpVz5mG5vH3Xzs1IrkVVnPu8uYkz q5lA== X-Gm-Message-State: AGi0PubL4csYgLRRXhF30q0Z0/JrZY9f0XbaGKOPUrk+l8m2OefI0LlQ ifLRC2nz1xI6IyJ9f9J8cYS9MhNcYgKRtmeY6yMK2g== X-Google-Smtp-Source: APiQypLOERCn1oDMroBRw3U1LnS/QuQYVCRZzBbceOWUD4WxJkkmjZK63mAMWn4aPIo9sJhzXicAaowMTWCu0/KtxjA= X-Received: by 2002:a50:9eac:: with SMTP id a41mr5601120edf.120.1589024436862; Sat, 09 May 2020 04:40:36 -0700 (PDT) MIME-Version: 1.0 References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> In-Reply-To: From: Robert Raszuk Date: Sat, 9 May 2020 13:40:28 +0200 Message-ID: Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Andrew Alston Cc: 6man WG Content-Type: multipart/alternative; boundary="0000000000001964cb05a53595ff" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 11:40:55 -0000 --0000000000001964cb05a53595ff Content-Type: text/plain; charset="UTF-8" > Robert I suggest you read the appeal - the psp issue is not the only issue > in the appeal - so while whatever is done here may resolve that issue - it > is hardly the only issue and resolving this would not render the entire > appeal moot - it would resolve that one point > > Andrew > I did. If we (here in 6man) define notion of IPv6 transit and agree that it is formally ok to modify IPv6 transit headers as it seems fit by the transit owner then: * Points 1-3 of the appeal no longer apply * Point 4 does not apply as format of the address again would be fully up to transit owner * Point 5 does not apply as it is not up to participants but up to transit owner to make sure it is deployable But I am seeing some emails asking AD if 6man can even formally do all of that ? If not 6man then who ? Conflict of interests & non technical process points 1-3 I am not going to comment on. I am also in no capacity questioning RFC2026. But even if any of them would be found real then what - draft comes back to SPRING, goes via another WGLC and goes back to IESG ? What is the point & benefit ? More process ? Cheers, Robert. --0000000000001964cb05a53595ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0
Robert I suggest you read the appeal - = the psp issue is not the only issue in the appeal - so while whatever is do= ne here may resolve that issue - it is hardly the only issue and resolving = this would not render the entire appeal moot - it would resolve that one point

Andrew=C2=A0

I did.=C2=A0

If we (here in 6man)= define notion of IPv6 transit and agree that it is formally ok to modify I= Pv6 transit headers as it seems fit by the transit owner then:=C2=A0
<= div>
* Points 1-3 of the appeal no longer apply
* P= oint 4 does not apply as format of the address again would be fully up to t= ransit owner
* Point 5=C2=A0 does not apply as it is not up to participants but up to transit owner to m= ake sure it is deployable

But I am seeing some ema= ils asking AD if 6man can even formally do all of that ? If not 6man then w= ho ?=C2=A0

Conflict of interests & non technic= al process points 1-3 I am not going to comment on. I am also in no capacit= y questioning RFC2026.=C2=A0

But even if any o= f them would be found real then what - draft comes back to SPRING, goes via= another=C2=A0WGLC and goes back to IESG ? What is the point & benefit = ?=C2=A0

More process ?

Ch= eers,
Robert.
=C2=A0
--0000000000001964cb05a53595ff-- From nobody Sat May 9 04:52:32 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7C63A0A13 for ; Sat, 9 May 2020 04:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 u-SiInLJOozY for ; Sat, 9 May 2020 04:52:28 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A873F3A0A1B for ; Sat, 9 May 2020 04:52:28 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4E7CC8087E; Sat, 9 May 2020 13:52:25 +0200 (CEST) Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 To: Robert Raszuk , Andrew Alston Cc: 6man WG References: <2dedad80-7a1b-4538-3d98-bc07e3e0420d@joelhalpern.com> From: Fernando Gont Message-ID: Date: Sat, 9 May 2020 08:52:14 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 11:52:31 -0000 On 9/5/20 08:40, Robert Raszuk wrote: > Robert I suggest you read the appeal - the psp issue is not the only > issue in the appeal - so while whatever is done here may resolve > that issue - it is hardly the only issue and resolving this would > not render the entire appeal moot - it would resolve that one point > > Andrew > > > I did. > > If we (here in 6man) define notion of IPv6 transit and agree that it is > formally ok to modify IPv6 transit headers as it seems fit by the > transit owner then: > > * Points 1-3 of the appeal no longer apply You don't fix the procedural issues represented by dismissing valid technical issues by trying to do spec-manship once an appeal has been filled. This is the equivalent of the responsible AD for spring trying to process and address WGLC comments once WGLC consensus had already been declared. I think you got the std process exactly backwards. > * Point 4 does not apply as format of the address again would be fully > up to transit owner > * Point 5 does not apply as it is not up to participants but up to > transit owner to make sure it is deployable > > But I am seeing some emails asking AD if 6man can even formally do all > of that ? If not 6man then who ? For the record, that's me making that claim. I'd have to check whether that'd be within the scope of int-area, or maybe a new wg might need to be created. The 6man charter says: "It is not chartered to develop major changes or additions to the IPv6 specifications. " Changing an e2e protocol into something that's not e2e, by allowing header insertion/removal in transit is certainly a major change/addition, and hence htat doesn't seem to me like within the scope of 6man. > But even if any of them would be found real then what - draft comes back > to SPRING, goes via another WGLC and goes back to IESG ? What is the > point & benefit ? Draft goes back to wg. Issues get addressed, or else document doesn't move forward. And WGLC is evaluated in a fair and non-biased way. > More process ? RFC2026-process. Which I believe has not happened for the network programming draft in spring. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat May 9 06:04:10 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420F43A0985 for ; Sat, 9 May 2020 06:04:08 -0700 (PDT) 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 ULZgRjGrbgs9 for ; Sat, 9 May 2020 06:04:05 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 463AF3A091E for ; Sat, 9 May 2020 06:04:05 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id b18so4037668ilf.2 for ; Sat, 09 May 2020 06:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eaLrrJ79Ykg7pvAAZevMTjGAjKAOvaRjcT5IkSWwfuQ=; b=GV7712VEq0hlLDpqn+iWqbyhbdiHbldfUGLZzyiQsozwz4+bW6wbtC3aENPd019bB+ 8s3WqjmOutaQJK7Q3xXy5tHP/VijRGXMbJ5kzL5OG1m171DEoYBhetXLgHrU8nxtSXrm KnDnthDudgPH8m+D87/3ZQSH6h0OrcIIqGJNzQLaquZQbBiHKcP+TBzNufnApfTg+oRj kIyNb/NDkvF1cAUZHfQw0BW1jWoww0x9XDKBNSMjLWrlc/RdRQxMQNvNGzABlN91bNog wbM5qL7mZVqHyLi0DmrwAtpVeh2uySigwthC8LNTLLnyM1YsJugfW9ag5ViXVwtcJw7M kn5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eaLrrJ79Ykg7pvAAZevMTjGAjKAOvaRjcT5IkSWwfuQ=; b=SalbdHKNXKvMOJ31eZinQPn0s63QlBtDZ+JO4i70AeIynLUIkl2bPEhptIE0DV7KUS 44aeseYi4fLB1hoUu6b+jcxfTHsIVhA7RBKKMVRbp/4rROITw9ezBMSNrr3B6BRD2yj/ rxHi3TUFO5mbEh776m4AutbNnqL0ARvvoE2U5Kf2cSCZlexU4+MPMPLYejHpTQ2YebES fEGjp6Bgzx35laz22CUx0jQ43aiR3ioFM+bzPf0+e387DOpM0zBFnEEBvwqf3XILnCB0 7C8oSfxMH3VURv831VKIRDiHqWoyAmrE4zRw89wiPNku6w+yFC9ZjpMweIyJ9LF5nOrp Qy4A== X-Gm-Message-State: AGi0PuZ5q4nkf4+w/X9pmoNLz62EOtwhF0qzsYbCpLmwrmWdOOFO+F0q pJceZUiLeTMbFdUYyFFkUW8iY9WNxSCPvBlXYUgdYKN1Rjg= X-Google-Smtp-Source: APiQypIjXTOFhdgmNDXoyiqvIHDqJoehHOxlTmX/SqIa0ocXeUyJ7MGkciAVcEiMheEH60oPXyY2lKFdjzXKASrdopM= X-Received: by 2002:a92:8350:: with SMTP id f77mr3641569ild.257.1589029444321; Sat, 09 May 2020 06:04:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sat, 9 May 2020 09:03:53 -0400 Message-ID: Subject: Re: whether to grant exception for SRV6 (Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: 6man WG , Robert Raszuk Content-Type: multipart/alternative; boundary="00000000000091075705a536bf4a" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 13:04:09 -0000 --00000000000091075705a536bf4a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 8, 2020 at 8:35 PM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Fri, 8 May 2020 19:27:53 -0400, > Gyan Mishra wrote: > > > Given that SRv6 PGM draft has left the station awaiting publication I > think > > the most prudent recourse for 6MAN is to grant the exception for SRV6 > > technology to allow insertion and removal on any transit node within th= e > > carriers administrative domain. > > Could we at least change the subject, please? (I'm now actually > changing it). > Gyan> That=E2=80=99s fine > > As Ron already clarified, while the unfortunate discussion for > draft-ietf-spring-srv6-network-programming was indeed a major > background motivation of draft-bonica-6man-ext-hdr-update-03, whether > 6man should grant the exception for SRV6 is irrelevant to it. It's > for the general protocol spec, rather than whatever exceptions grated > to the general protocol. > > But on a slightly related point on the relationship between these two: > I don't think "SRv6 PGM draft has left the station awaiting > publication" in the first place. It's not even in an IETF last call; > it can be returned to the WG at the AD evaluation stage, and even if > it passes the AD there will certainly be more discussions at the stage > of IETF last call. It's not uncommon that a proposal that passes a > WGLC is returned or even dropped in these phases. And, I'd certainly > oppose it if and when the draft reaches an IETF last call in its > current shape, since it's not distinguishable from an abuse of the > text bug of RFC8200 for an easy shortcut, attempting to avoid tougher > discussions. That's unfortunate especially because it seems to me > that PGM has a pretty good chance of justifying it as an exception > (though probably still controversial) and an update to RFC8200 in that > sense, instead of claiming it's just already standard compliant. > Gyan> I saw the draft in awaiting publication state and that it had already went through IETF LC. If it=E2=80=99s two late to pull back or contest this draft do you agree to= making an exception. I think at that point we have to from a 6MAN perspective so the standard is in sync with new technologies that have received WG adoption and have been deployed such as SRv6. This draft updates RFC 8200 so I think this draft should provide that exception if and when the train leaves the station. I agree their is a good chance that PGM can justify an exception. I asked Jingrong and a few others on a number of instances as to why PGM is necessary and technical merit as drawing parity to MPLS PHP implicit null is default on all routers, however issues have existed since Day 1 related to QOS scheduling on the PHP node when the MPLS label is popped form PE-P, and the workaround that has been employed has been explicit null pipe mode QOS groups tagging to preserve the exp markings from Ingress to egress. The respone from Spring given has been that for brownfield migration deployments or SRv6 that the PSP function allows the egress PE to be legacy and offloads the SRH removal to the one hop prior PSP P node. >From my experience working with MPLS as well as SR SR-MPLS and SRv6, all PEs have to be upgraded to support SRH SRv6 EH type 4 since all LSPs are unidirectional in both directions from ingress to egress so every PE acts as an Ingres PE as well as egress PE. I was given some use cases but they did not make sense to me as to why the LSP would only be in one direction. If Spring can convince the AD and IETF LC review that the hardware issue on the egress PE is a real mandatory issue that can only be ee > The expected meta discussion at that stage will be non-constructive, > and I suspect it can even take more time than just trying to justify > it as an exception/update due to its meta level controversy (in which > case it's also unfortunate for those who just want it to be published > sooner). My hope with draft-bonica-6man-ext-hdr-update-03 is that it > will prevent such unnecessary and unfortunate discussions in future, > if not for draft-ietf-spring-srv6-network-programming. > Gyan>. I agree that if we still have time to dispute the draft then their is no need to discuss PGM draft exceptions as it=E2=80=99s to early for tha= t and we need to stay course on plans to dispute PGM from a 6MAN perspective. I agree with the merit in the Bonica draft to prevent future occurrences of misinterpretation and violations of the draft by tightening up the verbiage= . > > -- > JINMEI, Tatuya > --=20 Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --00000000000091075705a536bf4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, M= ay 8, 2020 at 8:35 PM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp> wrote:=
At Fri, 8 May 202= 0 19:27:53 -0400,
Gyan Mishra <hayabusagsm@gmail.com> wrote:

> Given= that SRv6 PGM draft has left the station awaiting publication I think
&= gt; the most prudent recourse for 6MAN is to grant the exception for SRV6> technology to allow insertion and removal on any transit node within= the
> carriers administrative domain.

Could we at least chang= e the subject, please? =C2=A0(I'm now actually
changing it).

=C2= =A0 Gyan> That=E2=80=99s fine=C2=A0

As Ron already clarified, while the unfortu= nate discussion for
draft-ietf-spring-srv6-network-programming was indee= d a major
background motivation of draft-bonica-6man-ext-hdr-update-03, = whether
6man should grant the exception for SRV6 is irrelevant to it.=C2= =A0 It's
for the general protocol spec, rather than whatever excepti= ons grated
to the general protocol.

But on a slightly related poi= nt on the relationship between these two:
I don't think "SRv6 P= GM draft has left the station awaiting
publication" in the first pl= ace.=C2=A0 It's not even in an IETF last call;
it can be returned to= the WG at the AD evaluation stage, and even if
it passes the AD there w= ill certainly be more discussions at the stage
of IETF last call.=C2=A0 = It's not uncommon that a proposal that passes a
WGLC is returned or = even dropped in these phases.=C2=A0 And, I'd certainly
oppose it if = and when the draft reaches an IETF last call in its
current shape, since= it's not distinguishable from an abuse of the
text bug of RFC8200 f= or an easy shortcut, attempting to avoid tougher
discussions.=C2=A0 That= 's unfortunate especially because it seems to me
that PGM has a pret= ty good chance of justifying it as an exception
(though probably still c= ontroversial) and an update to RFC8200 in that
sense, instead of claimin= g it's just already standard compliant.
=C2=A0=C2=A0
=C2=A0 =C2=A0 Gyan= > =C2=A0I saw the draft in awaiting publication state and that it had al= ready went through IETF LC. =C2=A0

If it=E2=80=99s two late to pull back or contest this draft do y= ou agree to making an exception.=C2=A0 I think at that point we have to fro= m a 6MAN perspective so the standard is in sync with new technologies that = have received WG adoption and have been deployed such as SRv6.=C2=A0 This d= raft updates RFC 8200 so I think this draft should provide that exception i= f and when the train leaves the station.

<= div dir=3D"auto">I agree their is a good chance that PGM can justify an exc= eption.

I asked Jingrong= and a few others on a number of instances as to why PGM is necessary and t= echnical merit as drawing parity to MPLS PHP implicit null is default on al= l routers, however issues have existed since Day 1 related to QOS schedulin= g on the PHP node when the MPLS label is popped form PE-P, and the workarou= nd that has been employed has been explicit null pipe mode QOS groups taggi= ng to preserve the exp markings from Ingress to egress.

The respone from Spring given has been that= for brownfield migration deployments or SRv6 that the PSP function allows = the egress PE to be legacy and offloads the SRH removal to the one hop prio= r PSP P node. =C2=A0

Fro= m my experience working with MPLS as well as SR SR-MPLS and SRv6, all PEs h= ave to be upgraded to support SRH SRv6 EH type 4 since all LSPs are unidire= ctional in both directions from ingress to egress so every PE acts as an In= gres PE as well as egress PE.=C2=A0 I was given some use cases but they did= not make sense to me as to why the LSP would only be in one direction.=C2= =A0 If Spring can convince the AD and IETF LC review that the hardware issu= e on the egress PE is a real mandatory issue that can only be ee



The expected meta discussion at that= stage will be non-constructive,
and I suspect it can even take more tim= e than just trying to justify
it as an exception/update due to its meta = level controversy (in which
case it's also unfortunate for those who= just want it to be published
sooner).=C2=A0 My hope with draft-bonica-6= man-ext-hdr-update-03 is that it
will prevent such unnecessary and unfor= tunate discussions in future,
if not for draft-ietf-spring-srv6-network-= programming.
=C2=A0
=C2=A0 Gyan>. I agree that if we still have time to d= ispute the draft then their is no need to discuss PGM draft exceptions as i= t=E2=80=99s to early for that and we need to stay course on plans to disput= e PGM =C2=A0from a 6MAN perspective.=C2=A0 I agree with the merit in the Bo= nica draft to prevent future occurrences of misinterpretation and violation= s of the draft by tightening up the verbiage.

--
JINM= EI, Tatuya
--

Gyan=C2=A0 Mishra<= /font>

Network Engineering & Technology=C2=A0

Silver Spring, MD 20904

P= hone: 301 502-1347

Email: gyan.s.mishra@verizon.com



--00000000000091075705a536bf4a-- From nobody Sat May 9 06:21:38 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E7A3A0A9D for ; Sat, 9 May 2020 06:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BRDHhKfv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=STI+JXo3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h05MI6OhJiyB for ; Sat, 9 May 2020 06:21:32 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F055A3A0A9C for ; Sat, 9 May 2020 06:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46979; q=dns/txt; s=iport; t=1589030491; x=1590240091; h=from:to:cc:subject:date:message-id:mime-version; bh=Pvr4EhnNpjFdNYJwjcf1aGnkZLz376gC9CT5PRw+DO4=; b=BRDHhKfvu19zbD+8Zhd8z0Q/CeQtU3/UNrun4DiGcezVuLfu5NuVknfL vF1YWAPdgoU2Zf0zuP2aLFgQHIrpgKHLghY4rRnB2O8LMnObDihQR7rLr tFQ4t4cAMwKJUaLSfTgWayIfaFdFaZWsG8M4OvngdGcwGeQ3BD5z2IG6/ k=; IronPort-PHdr: =?us-ascii?q?9a23=3AvwCNMhUO6LNDxU/3I2x5/v19/5bV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+FufBDhu7WuqT4VHYGp52GtSNKfJ9NUk?= =?us-ascii?q?oDjsMb10wlDdWeAEL2ZPjtc2QhHctEWVMkmhPzMUVcFMvkIVGHpHq04G0QHR?= =?us-ascii?q?j7NQNxPunvHMjZiMHkn+y38ofYNgNPgjf1aLhuLRKw+APWsMRegYZrJqsrjB?= =?us-ascii?q?XTpX4dcOVNzmQuLlWWzBs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AQDcrbZe/5NdJa1iAxwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBgXYEAQELAYEkLyQtBW9YLywKhBqDRgONHYofjj2BQoEQA1A?= =?us-ascii?q?ECwEBAQwBARgBDAgCBAEBhEQCF4F3JDcGDgIDAQELAQEFAQEBAgEFBG2FVgy?= =?us-ascii?q?FcQECAQEDARARHQEBJQcLAQ0EARkDAQIhAQIEAwIEGQYGCxQJCgQBDQUigwQ?= =?us-ascii?q?BgX5NAy4BAgyjYQKBOYhhdoEygwEBAQWBNgIOQYMkDQuCDgMGBYEzAYJiiWE?= =?us-ascii?q?agUE/gRABJwwQgwuCHkkBAQEBAQGBKAQBEgEnEQkBBQcJEYJNM4ItjkqDCIY?= =?us-ascii?q?eim+PRkoKgkqIG4s7hFIdglyIZ5F3hHGGL4R9gViIAoJHkQkCBAIEBQIOAQE?= =?us-ascii?q?FgWgjZnBwFTsqAYI+UBgNkEAMBRIVgzqFFIVCdAIyAwIGAQcBAQMJfIp3gTU?= =?us-ascii?q?BgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,371,1583193600"; d="scan'208,217";a="503372658" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 May 2020 13:21:27 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 049DLRbq011440 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 May 2020 13:21:27 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 9 May 2020 08:21:27 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 9 May 2020 09:21:25 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 9 May 2020 09:21:25 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PFgRhRje21W+tfBrfesBTSFyz4S6uUgclBKFhFPrVGDzCkP4QNjwDkEWTtxQRmvT+OLWWmArv/aRSOrA1rGEjJmGtGTxPJGbm6v0M66jGKWAsgjkU8uxPoROzbmXWkHKOgup8or6FxBUP9ZHQvLGELb+xbDg+ufUgQ+vd9BFoeFKAmgbek4y2l4Ay6Xj4QcrWHYV3t7J06q321nCTP6X+x2r7vmvCmbWTp+/l+qOP6d2FH34rJVFquk8o4UHYWd38Dy5nP1to5tzsVu22a2pcESwD2KZXkhmVwccfd0soSekiYvcsEV35CUDEcK0zqJ0DJiS4mg1bSfpDAULn4JH2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pvr4EhnNpjFdNYJwjcf1aGnkZLz376gC9CT5PRw+DO4=; b=Fy9/HCXh2kUX1U3WtEWG7yvSkHcVBHwOpYylou2kZc0RF4lRc/iUAy3bTMCqSRpbKRFih2wr9oqsE/HpEKI2TKdqkPIltE1gnOWHQlp2dmMrNIFU+S+Q+Z7ORc70HKJfLpamYiBGAMrTTcOqeuqU/wIcJs6Q7CSFOo0C9YC7mQHXMo0uc2PCh8RFAfCP6ZrThtlFPVO9bBmlZFwfKAVtDlPw3LE3RyqpU/oQZP0atHt0Bjf3USOWtdVYBI5FsaBgGPo09dIHwazuVxj2pyVzBusPMoJ2qwabRLN5Pu8ZBFYHV/9C8yakyEEgqaUzmLPTGbPb6fuIg4fZOK9qx152tQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pvr4EhnNpjFdNYJwjcf1aGnkZLz376gC9CT5PRw+DO4=; b=STI+JXo3bYDZnQJqzg0NWdeOtyo9IInDeNSY7irjOE2+QVQXT7+Mv2QPQL2fWVX8JCn0fIz7ZvJE1YeuY9Y6HC+HnZ8NOE8jdg8EoSLJ2rGE5F6ka3/OViBiqkOYeYQEGdSKdonKBmwK7bOC6MvrLXY/YNNSVigf8DnIC5zQafw= Received: from DM6PR11MB4692.namprd11.prod.outlook.com (2603:10b6:5:2aa::11) by DM6PR11MB2907.namprd11.prod.outlook.com (2603:10b6:5:64::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26; Sat, 9 May 2020 13:21:24 +0000 Received: from DM6PR11MB4692.namprd11.prod.outlook.com ([fe80::6c2a:f5fa:44b9:f30b]) by DM6PR11MB4692.namprd11.prod.outlook.com ([fe80::6c2a:f5fa:44b9:f30b%3]) with mapi id 15.20.2979.033; Sat, 9 May 2020 13:21:24 +0000 From: "Zafar Ali (zali)" To: "Joel M. Halpern" , Gyan Mishra CC: "Zafar Ali (zali)" , 6man WG Subject: Net-PGM does NOT contain insertion behavior : was: - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 Thread-Topic: Net-PGM does NOT contain insertion behavior : was: - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03 Thread-Index: AQHWJgS8D4gdUY562UG6bfojU6OWVA== Date: Sat, 9 May 2020 13:21:23 +0000 Message-ID: <95C75820-D887-4053-8FB3-AF589018658B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [47.185.212.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22170b58-7933-4ecf-bd93-08d7f41bdf24 x-ms-traffictypediagnostic: DM6PR11MB2907: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3173; x-forefront-prvs: 03982FDC1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NvrOepoj5IKobsRrJprZ+AKDnoIeiRwPLG6sVrPUd75LVOeRAEcxZrO3/SMkLQCFlGx4lRvKjTlAOeAudtDYs/m+Uukju1dzf9AdiMSlO9Uq65f1JJ+RfKcLnE/8yZXNYHNjyUu66RUz1+tLI9MY0ZeXlKdLiOUh0o5hs3XaSUcgZwE69Fok/opWci9Ae3+mTB5jSI+qop00isTN37vFxHiNmUQ9iK4mlo+yAfUHI5osgpAH450HkD/xqzoVZsPKrlS5FiCvQjQFyXXiLLcM5VtYFpBYRXmSrueecCh3IOMpddcLGoEc/sO61tzKfwCGPGtaHc66cMKjAqsddj0oHxijdtGWR6b0tlhRGKnTiCbazEvb8msPDT8qk5ZdWxc0yHt1vh7kVyhqN3q0MxJyWmE1Cc9qbJSKK4wncc5h270WoqT3B3zMv/4dOzpo6umYUenOHDB9+rvh4px8usFn5BqHkQRqZJMlUEb7eIIH1tIK6Jhnkc7dW9PZC/y9Yy2u+NhluxuLrd2ap5cIjrwtb1gptdqShENEkVIssaU8/OXFBG21c8nJE+EozcC6RogAO1w14+3SzB2M0QpsKiuXEBky0L9DKT1kve38oIEkAoU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4692.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(376002)(366004)(346002)(33430700001)(53546011)(110136005)(76116006)(54906003)(33440700001)(5660300002)(316002)(966005)(8936002)(8676002)(33656002)(66556008)(66946007)(64756008)(26005)(4326008)(66574014)(36756003)(86362001)(71200400001)(66446008)(186003)(6506007)(15650500001)(2906002)(2616005)(6512007)(6486002)(478600001)(166002)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FJBVGGVH1jRNQjkERPrbMVbQ8kPFO/4nOm/K9VPB3scD8xjTEJb7Z0CEoKhxqg0vVOiMiHXgkRaF1D3qwR6i7jm73hfLr2cBz9jD4gCDe1xp70S7nS/3dzTt4Td3T2V0RXdoBOi7kxy1oq6zulkHPzw5rtmdja5Y64/d+6OeTYiB665FfjxNg12doAkAJufBAWvmZUmlPQnP7XtEpE2oZdWhZpzGhqnwS5VVtmUP1I+6nJHkqEbgsrNCwvqP3Me+b5YxsRnZdzgRgKevHTqQypfuIOImCBqBVUXucIbdvE/NdyQwAnHUaB0cDUIwsHYXIRs5k0mKnlUSU855FNtiovTvjZV6+9M9z8gPY6zt8w03dDnOB3DFqqxW/QNkkpiPiHebOuqTvHtRMdawV9RmiZcjTz2JES7ijH8VMcgkQy0s4zwLVEF8log1Hd+W7RePrVUu4UQKEIdTC1lkcwgNRbYcOpNzQ137b2cHDi1ZdmcqXaTkAUCzkNMeBXOgD0q0 Content-Type: multipart/alternative; boundary="_000_95C75820D88740538FB3AF589018658Bciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 22170b58-7933-4ecf-bd93-08d7f41bdf24 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2020 13:21:24.0439 (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: z1eX4A9f/GQ1G+RvGrp/dgxPF9RYRjstHjKi9es5Fnwnh3DaB3NumRopNhRX8lXx X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2907 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 13:21:35 -0000 --_000_95C75820D88740538FB3AF589018658Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lbCwgdGhlIFdHLA0KDQpDaGFuZ2luZyB0aGUgc3ViamVjdCB0byBoaWdobGlnaHQgd2hh dCBKb2VsIG1lbnRpb25lZC4NCg0KZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dy YW1taW5nIGRvZXMgTk9UIGNvbnRhaW4gdGV4dCByZWxhdGVkIHRvIFNSSCBpbnNlcnRpb24uDQoN ClNSSCBpbnNlcnRpb24gaW4gdGhlIGNvbnRleHQgb2YgbmV0d29yayBwcm9ncmFtbWluZyBpcyBh biBpbmRpdmlkdWFsIGRvY3VtZW50IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Zmlsc2ZpbHMtc3ByaW5nLXNydjYtbmV0LXBnbS1pbnNlcnRpb24tMDIpLCB3aGljaCByZWxpZXMg b24gY29uc2lkZXJhdGlvbnMgZGVzY3JpYmVkIGluIGEgNm1hbiBkb2N1bWVudCwgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdm95ZXItNm1hbi1leHRlbnNpb24taGVhZGVy LWluc2VydGlvbi8gKC0wMCB3YXMgc3VibWl0dGVkIGluIE1hcmNoIDIwMTcpLg0KDQpUaGFua3MN Cg0KUmVnYXJkcyDigKYgWmFmYXINCg0KDQpGcm9tOiBpcHY2IDxpcHY2LWJvdW5jZXNAaWV0Zi5v cmc+IG9uIGJlaGFsZiBvZiAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4N CkRhdGU6IEZyaWRheSwgTWF5IDgsIDIwMjAgYXQgNzozMyBQTQ0KVG86IEd5YW4gTWlzaHJhIDxo YXlhYnVzYWdzbUBnbWFpbC5jb20+DQpDYzogNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBzb21lIGZlZWRiYWNrIG9uIGZlZWRiYWNrIG9uIGRyYWZ0LWJvbmljYS02bWFuLWV4 dC1oZHItdXBkYXRlLTAzDQoNClRoZSBTUnY2IFBHTSBkb2N1bWVudCB0aGF0IHdhcyBhcHByb3Zl ZCBkb2VzIG5vdCBkbyBhcmJpdHJhcnkgaW5zZXJ0aW9uLg0KICBJdCBkb2VzIHRoZSB2ZXJ5IHNw ZWNpZmljIFBTUCByZW1vdmFsLiAgSSB0aGluayBpdCBpbmFwcHJvcHJpYXRlIGZvcg0KdXMgdG8g c2F5IHRoYXQgZ2l2ZW4gdGhhdCB0aGlzIG9uZSBwaWVjZSB3YXMgYWxsb3dlZCwgYW55dGhpbmcg YW5kDQpldmVyeXRoaW5nIHNob3VsZCBiZSBhbGxvd2VkLg0KDQpBbHNvLCBpdCBpcyBub3JtYWwg Zm9yIFJGQ3MgdG8gYmUgdW5kZXJzdG9vZCB0byBiZSBvbmx5IGFwcGxpY2FibGUgZ29pbmcNCmZv cndhcmQuICBUaGUgbW9zdCB0aGF0IHNob3VsZCBiZSBzYWlkIGFib3V0IFBTUCBpbiB0aGlzIGRy YWZ0DQpleHBsaWNpdGx5IHdvdWxkIGJlIGEgbm90ZSBpbmRpY2F0aW5nIHRoYXQgdGhlIFBTUCBi ZWhhdmlvciBwcmVkYXRlcw0KdGhpcywgYW5kIGlzIG5vdCBhZmZlY3RlZCBieSBpdC4NCg0KQW5k IGV2ZW4gdGhhdCBtdWNoIHdvdWxkIHdhaXQgb24gdGhlIHJlc29sdXRpb24gb2YgdGhlIHBlbmRp bmcgYXBwZWFsIG9uDQp0aGUgdG9waWMuDQoNCllvdXJzLA0KSm9lbA0KDQpPbiA1LzgvMjAyMCA3 OjI3IFBNLCBHeWFuIE1pc2hyYSB3cm90ZToNCg0KR2l2ZW4gdGhhdCBTUnY2IFBHTSBkcmFmdCBo YXMgbGVmdCB0aGUgc3RhdGlvbiBhd2FpdGluZyBwdWJsaWNhdGlvbiBJDQp0aGluayB0aGUgbW9z dCBwcnVkZW50IHJlY291cnNlIGZvciA2TUFOIGlzIHRvIGdyYW50IHRoZSBleGNlcHRpb24gZm9y DQpTUlY2IHRlY2hub2xvZ3kgdG8gYWxsb3cgaW5zZXJ0aW9uIGFuZCByZW1vdmFsIG9uIGFueSB0 cmFuc2l0IG5vZGUNCndpdGhpbiB0aGUgY2FycmllcnMgYWRtaW5pc3RyYXRpdmUgZG9tYWluLg0K DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zcnY2 LW5ldHdvcmstcHJvZ3JhbW1pbmcvDQoNCkRvY3VtZW50ICAgICAgVHlwZSAgICAgICAgICAgICAg ICAgICAgICBBY3RpdmUgSW50ZXJuZXQtRHJhZnQgKHNwcmluZyBXRw0KPGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvd2cvc3ByaW5nLz48aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93 Zy9zcHJpbmcvJTNlPikNCiAgICAgICAgICAgTGFzdCB1cGRhdGVkICAgICAgICAgICAgICAgICAg ICAgIDIwMjAtMDQtMTQgKGxhdGVzdCByZXZpc2lvbiAyMDIwLTAzLTI3KQ0KICAgICAgICAgICBS ZXBsYWNlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWZpbHNmaWxzLXNwcmlu Zy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmcNCjxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1maWxzZmlscy1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLz4NCiAg ICAgICAgICAgU3RyZWFtICAgICAgICAgICAgICAgICAgSUVURg0KICAgICAgICAgICBJbnRlbmRl ZCBSRkMgc3RhdHVzICAgICAgICAgICAgICAgICAgICAgICAgUHJvcG9zZWQgU3RhbmRhcmQNCiAg ICAgICAgICAgRm9ybWF0cyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBsYWluIHRl eHQNCjxodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5ldHdv cmstcHJvZ3JhbW1pbmctMTUudHh0Pg0KICAgeG1sDQo8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQv ZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLTE1LnhtbD4NCiAgIHBk Zg0KPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcGRmL2RyYWZ0LWlldGYtc3ByaW5nLXNydjYtbmV0 d29yay1wcm9ncmFtbWluZy0xNS5wZGY+IGh0bWxpemVkDQoodG9vbHMpDQo8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWlu Zy0xNT4NCiAgIGh0bWxpemVkDQo8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmctMTU+IGJpYnRleA0K PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5nLXNydjYt bmV0d29yay1wcm9ncmFtbWluZy9iaWJ0ZXg+DQpTdHJlYW0gICAgICAgICAgICBXRyBzdGF0ZSA8 aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9oZWxwL3N0YXRlL2RyYWZ0L2lldGY+DQpTdWJt aXR0ZWQgdG8gSUVTRyBmb3IgUHVibGljYXRpb24NCiAgICAgICAgICAgRG9jdW1lbnQgc2hlcGhl cmQgICAgICAgICAgICAgICAgICAgICAgIEJydW5vIERlY3JhZW5lDQoNCg0KSW4gdGhlIHZlcmJp YWdlIGFzIHRvIHJlYXNvbnMgd2h5IHRoaXMgYmVpbmcgYWxsb3dlZCBpcyB0aGF0IFNSdjYgd291 bGQNCmFsd2F5cyBiZSB1c2VkIGluIGEgY2xvc2VkIGRvbWFpbiB3aXRoIHN0YW5kYXJkIHNlY3Vy aXR5IHByb3RlY3Rpb24NCm1lY2hhbmlzbXMgYXQgaW5ncmVzcyBhbmQgZWdyZXNzIG9mIHRoZSBk b21haW4uICBEb21haW4gZGVmaW5pdGlvbiB3b3VsZA0KaGF2ZSB0byBiZSBkZWZpbmVkIGFzIGEg Y2FycmllcnMgYWRtaW5pc3RyYXRyYXRpdmUgZG9tYWluIHdoZXJlIHRoZQ0KY2FycmllcnMgdHJh bnNwb3J0IG5ldHdvcmsgY291bGQgc3BhbiBtdWx0aXBsZSBBU3MgdGhhdCBhcmUgaW50ZXINCmNv bm5lY3RlZCB2aWEgU1ItVEUgYnNpZCBvciBpbnRlci1hcyBMMyB2cG4uDQoNCk9uZSBjYXZlYXQg bG9vcGhvbGUgZG9lcyBleGlzdCBpcyB0aGF0IGludGVyIGFkbWluaXN0cmF0aXZlIGRvbWFpbg0K aW50ZW50IGJhc2VkIFNSIGZsb3dzIHdvdWxkIGFsc28gYmUgYWxsb3dlZCBzbyBpbiB0aGVvcnkg eW91IGNvdWxkIGhhdmUNCmEgY2hhaW4gb2YgU1JWNiBkb21haW5zIG92ZXIgdGhlIGludGVybmV0 IG9yIGV2ZW4gcHJpdmF0ZSBpbnRlcg0KY29ubmVjdGVkIGRvbWFpbnMgc28gdGhlbiBtYXliZSBu b3QgYm90aGVyIHdpdGggdGhlIGRvbWFpbiBjb25jZXB0IGFzIGl0DQpyZWFsbHkgZ29lcyBvdXQg dGhlIHdpbmRvdy4NCg0KU28gdGhlbiBpdOKAmXMganVzdCBhbiBleGNlcHRpb24gdG8gYWxsb3cg U1J2NiB0byBkbyBhcyB0aGV5IHBsZWFzZSBhcw0KaW1wb3NzaWJsZSB0byBjb250cm9sIGF0IHRo YXQgcG9pbnQgc28gYW55IGFuZCBhbGwgdXNlIGNhc2VzIG9mIFNSdjYNCndvdWxkIGJlIGdyYW50 ZWQgdGhlIGV4Y2VwdGlvbi4NCg0KQXMgUm9iZXJ0IG1lbnRpb25lZCB0aGF0IGl04oCZcyB0aGUg Y2FycmllcnMgZG9tYWluIHNvIHRoZXkgaGF2ZSB0byB0YWtlDQpjYXJlIG9mIGFueSBzZWN1cml0 eSBpc3N1ZXMgcmVsYXRlZCB0byBBSCBvbiB0aGUgU1J2NiBvdXRlciBJUFY2DQp0cmFuc3BvcnQg aGVhZGVyLg0KDQpBbHNvIGFzIG5vdGVkIGJ5IFJvYmVydCB0aGF0IGFsbCBjdXN0b21lciB0cmFm ZmljIGlzIGtlcHQgaW4gdGFjdCBhbmQNCm5vdCBhbHRlcmVkIGFuZCB0aGF0IG5vIGluc2VydGlv biBvciByZW1vdmFsIG9mIGFueSBFSCBoZWFkZXJzIG9jY3VycyB0bw0KdGhlIGlubmVyIGhlYWRl ciBjdXN0b21lciBwYXlsb2FkLiAgU28gbm8gaW1wYWN0IHRvIGN1c3RvbWVycyB1c2Ugb2YgQUgN CmV0YyBhcyB0aGF0IGlzIHJlbWFpbnMgdW5hbHRlcmVkLg0KDQpUaGFua3MNCg0KR3lhbg0KDQoN Cg0KDQpPbiBGcmksIE1heSA4LCAyMDIwIGF0IDc6MDYgUE0gUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0 QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pg0KPG1haWx0bzpyb2JlcnRAcmFz enVrLm5ldD48bWFpbHRvOnJvYmVydEByYXN6dWsubmV0JTNlPj4gd3JvdGU6DQoNCiAgICAgSGkg UGhpbGlwLA0KDQogICAgIFNvdW5kcyB2ZXJ5IHJlYXNvbmFibGUuDQoNCiAgICAgSU1PIHdoYXQg aXMgbmVlZGVkIGhlcmUgaXMgYSBzaG9ydCBzcGVjIHdoaWNoIHdvdWxkIGV4cGxpY2l0bHkgY2Fs bA0KICAgICBvdXQgdGhlIGNhc2Ugb2YgdXNpbmcgSVB2NiBhcyB0cmFuc3BvcnQgbGF5ZXIuIFRo ZW4gaXQgd291bGQgYWxsb3cNCiAgICAgdGhlIHRyYW5zcG9ydCBvd25lciBzdWZmaWNpZW50IGZs ZXhpYmlsaXR5IChpbnNlcnRpb24sIG1vZGlmaWNhdGlvbiwNCiAgICAgZGVsZXRpb24pIGludG8g YXBwbGllZCBieSBoaXMgb3duIGluZ3Jlc3MgbmV3IElQdjYgaGVhZGVyIGF0IGFueQ0KICAgICB0 cmFuc2l0IGhvcCBoZSBzZWVtcyByZXF1aXJlZC4gVWx0aW1hdGUgZ29hbCBpcyB0byBkZWxpdmVy IGNhcnJpZWQNCiAgICAgcGF5bG9hZCAoaGVyZSBvcmlnaW5hbCBJUHY2IG9yIElQdjQgcGFja2V0 cykgdmlhIGEgZ2l2ZW4gbmV0d29yayB0aGUNCiAgICAgYmVzdCBxdWFsaXR5IHBvc3NpYmxlLg0K DQogICAgIFRoeCBhIGxvdCwNCiAgICAgUm9iZXJ0Lg0KDQoNCiAgICAgT24gU2F0LCBNYXkgOSwg MjAyMCBhdCAxMjo0MiBBTSBQaGlsaXAgSG9tYnVyZw0KICAgICA8cGNoLWlwdjYtaWV0Zi02QHUt MS5waGljb2guY29tPG1haWx0bzpwY2gtaXB2Ni1pZXRmLTZAdS0xLnBoaWNvaC5jb20+DQogICAg IDxtYWlsdG86cGNoLWlwdjYtaWV0Zi02QHUtMS5waGljb2guY29tPjxtYWlsdG86cGNoLWlwdjYt aWV0Zi02QHUtMS5waGljb2guY29tJTNlPj4gd3JvdGU6DQoNCiAgICAgICAgICA+Tm93IGNvbWVz IHRoZSB0b3BpYyBvZiBhbiBhZGRpdGlvbmFsIGhhbmRlciBtYW5nbGluZyBldmVuIGJ5DQogICAg ICAgICBub2RlcyB3aGljaA0KICAgICAgICAgID5hcmUgbm90IGludGVybWVkaWF0ZSBkZXN0aW5h dGlvbnMsIHlldCBhbGwgd2l0aGluIHRyYW5zaXQNCiAgICAgICAgIG5ldHdvcmsuDQoNCiAgICAg ICAgIFNvIHRoaXMgaXMgdGhlIGtleSBwb2ludC4gUkZDIDgyMDAgYXBwbGllcyB0byBhbGwgSVB2 NiBwYWNrZXRzLg0KICAgICAgICAgU28gaWYNCiAgICAgICAgIFJGQyA4MjAwIGFsbG93cyBhZGRp dGlvbmFsIGhlYWRlciBtYW5nbGluZywgdGhlbiB0aGF0IGNhbiBoYXBwZW4NCiAgICAgICAgIGlu IGxvdHMgb2YNCiAgICAgICAgIG90aGVyIHBsYWNlcyBhcyB3ZWxsLCB3aGljaCBpcyBxdWl0ZSB1 bmRlc2lyYWJsZS4NCg0KICAgICAgICAgU28gUkZDIDgyMDAgaGFzIHRvIHN0YXRlIHRoYXQgaW4g Z2VuZXJhbCB0aGlzIHNvcnQgb2YgdGhpbmcNCiAgICAgICAgIGNhbm5vdCBoYXBwZW4uDQogICAg ICAgICBOZXh0IHdlIGNhbiB1cGRhdGUgUkZDIDgyMDAgd2l0aCBhIG5hcnJvd2x5IGNyYWZ0ZWQg ZXhjZXB0aW9uDQogICAgICAgICB0YWlsb3JlZCB0bw0KICAgICAgICAgdGhpcyB1c2UgY2FzZS4N Cg0KICAgICAgICAgV2UgaGF2ZSB0d28gcG9zc2liaWxpdGllczoNCiAgICAgICAgIC0gZWl0aGVy IFJGQyA4MjAwIGFsbG93cyBtYW5nbGluZyBieSBob3BzIGluIGEgcm91dGluZyBoZWFkZXIuDQog ICAgICAgICBJbiB0aGF0DQogICAgICAgICAgICBjYXNlIHdlIGhhdmUgYSBwcm9ibGVtIHRoYXQg bmVlZHMgdG8gYmUgZml4ZWQgd2hpbGUgY3JlYXRpbmcNCiAgICAgICAgIGFuIGV4Y2VwdGlvbg0K ICAgICAgICAgICAgZm9yIHNlZ21lbnQgcm91dGluZywgb3INCiAgICAgICAgIC0gUkZDIDgyMDAg ZG9lcyBub3QgYWxsb3cgdGhpcyBraW5kIG9mIG1hbmdsaW5nIGFuZCB3ZSBuZWVkIHRvDQogICAg ICAgICBjcmVhdGUgYW4NCiAgICAgICAgICAgIGV4Y2VwdGlvbiBmb3Igc2VnbWVudCByb3V0aW5n Lg0KDQoNCiAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFp bGluZyBsaXN0DQogICAgIGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+IDxtYWls dG86aXB2NkBpZXRmLm9yZz4NCiAgICAgQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KICAgICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQot LQ0KDQpHeWFuICBNaXNocmENCg0KTmV0d29yayBFbmdpbmVlcmluZyAmIFRlY2hub2xvZ3kNCg0K VmVyaXpvbg0KDQpTaWx2ZXIgU3ByaW5nLCBNRCAyMDkwNA0KDQpQaG9uZTogMzAxIDUwMi0xMzQ3 DQoNCkVtYWlsOiBneWFuLnMubWlzaHJhQHZlcml6b24uY29tPG1haWx0bzpneWFuLnMubWlzaHJh QHZlcml6b24uY29tPiA8bWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20+DQoNCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlwdjZA aWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlw djZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0 czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQo= --_000_95C75820D88740538FB3AF589018658Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1DC24A7529DFF049B188E6E6075D4EA6@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt dGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxNDQ0NzIyNzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0xNzE3MjU2NDQ0IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5IaSBKb2VsLCB0aGUgV0cs IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoYW5naW5nIHRoZSBzdWJqZWN0IHRvIGhpZ2hs aWdodCB3aGF0IEpvZWwgbWVudGlvbmVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmRyYWZ0 LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZyBkb2VzIE5PVCBjb250YWluIHRl eHQgcmVsYXRlZCB0byBTUkggaW5zZXJ0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNS SCBpbnNlcnRpb24gaW4gdGhlIGNvbnRleHQgb2YgbmV0d29yayBwcm9ncmFtbWluZyBpcyBhbiBp bmRpdmlkdWFsIGRvY3VtZW50ICg8L3NwYW4+PHU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsdWUiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1maWxzZmlscy1zcHJpbmctc3J2Ni1uZXQtcGdtLWluc2VydGlv bi0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZpbHNmaWxzLXNwcmluZy1z cnY2LW5ldC1wZ20taW5zZXJ0aW9uLTAyPC9hPjwvc3Bhbj48L3U+PHU+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4pPC9zcGFuPjwvdT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiwNCiB3aGljaCByZWxpZXMg b24gY29uc2lkZXJhdGlvbnMgZGVzY3JpYmVkIGluIGEgNm1hbiBkb2N1bWVudCwgPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdm95ZXItNm1hbi1leHRlbnNp b24taGVhZGVyLWluc2VydGlvbi8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtdm95ZXItNm1hbi1leHRlbnNpb24taGVhZGVyLWluc2VydGlvbi88L2E+ICgtMDAgd2Fz IHN1Ym1pdHRlZCBpbiBNYXJjaCAyMDE3KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJlZ2FyZHMg4oCmIFphZmFy IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5pcHY2ICZsdDtpcHY2LWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtKb2VsIE0uIEhhbHBlcm4mcXVv dDsgJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwg TWF5IDgsIDIwMjAgYXQgNzozMyBQTTxicj4NCjxiPlRvOiA8L2I+R3lhbiBNaXNocmEgJmx0O2hh eWFidXNhZ3NtQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPjZtYW4gV0cgJmx0O2lwdjZA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBzb21lIGZlZWRiYWNrIG9uIGZl ZWRiYWNrIG9uIGRyYWZ0LWJvbmljYS02bWFuLWV4dC1oZHItdXBkYXRlLTAzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgU1J2 NiBQR00gZG9jdW1lbnQgdGhhdCB3YXMgYXBwcm92ZWQgZG9lcyBub3QgZG8gYXJiaXRyYXJ5IGlu c2VydGlvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7SXQgZG9lcyB0aGUgdmVyeSBzcGVjaWZpYyBQU1AgcmVtb3ZhbC4m bmJzcDsmbmJzcDtJIHRoaW5rIGl0IGluYXBwcm9wcmlhdGUgZm9yDQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnVzIHRvIHNheSB0aGF0IGdpdmVu IHRoYXQgdGhpcyBvbmUgcGllY2Ugd2FzIGFsbG93ZWQsIGFueXRoaW5nIGFuZA0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ldmVyeXRoaW5nIHNo b3VsZCBiZSBhbGxvd2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbHNvLCBpdCBpcyBub3JtYWwgZm9yIFJGQ3MgdG8gYmUgdW5kZXJzdG9v ZCB0byBiZSBvbmx5IGFwcGxpY2FibGUgZ29pbmcNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Zm9yd2FyZC4mbmJzcDsmbmJzcDtUaGUgbW9zdCB0 aGF0IHNob3VsZCBiZSBzYWlkIGFib3V0IFBTUCBpbiB0aGlzIGRyYWZ0DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmV4cGxpY2l0bHkgd291bGQg YmUgYSBub3RlIGluZGljYXRpbmcgdGhhdCB0aGUgUFNQIGJlaGF2aW9yIHByZWRhdGVzDQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoaXMsIGFu ZCBpcyBub3QgYWZmZWN0ZWQgYnkgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBldmVuIHRoYXQgbXVjaCB3b3VsZCB3YWl0IG9uIHRo ZSByZXNvbHV0aW9uIG9mIHRoZSBwZW5kaW5nIGFwcGVhbCBvbg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgdG9waWMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXJzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9lbDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA1LzgvMjAy MCA3OjI3IFBNLCBHeWFuIE1pc2hyYSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJp Z2h0OjBpbiIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2l2ZW4gdGhhdCBTUnY2IFBHTSBkcmFmdCBoYXMgbGVm dCB0aGUgc3RhdGlvbiBhd2FpdGluZyBwdWJsaWNhdGlvbiBJDQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoaW5rIHRoZSBtb3N0IHBydWRlbnQg cmVjb3Vyc2UgZm9yIDZNQU4gaXMgdG8gZ3JhbnQgdGhlIGV4Y2VwdGlvbiBmb3INCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U1JWNiB0ZWNobm9s b2d5IHRvIGFsbG93IGluc2VydGlvbiBhbmQgcmVtb3ZhbCBvbiBhbnkgdHJhbnNpdCBub2RlDQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpdGhp biB0aGUgY2FycmllcnMgYWRtaW5pc3RyYXRpdmUgZG9tYWluLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3Jh bW1pbmcvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmlu Zy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmcvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2N1bWVudDxzcGFuIGNsYXNzPSJhcHBsZS10 YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5UeXBlPHNwYW4g Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5BY3RpdmUgSW50ZXJu ZXQtRHJhZnQgKHNwcmluZyBXRyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L3dnL3NwcmluZy8lM2UiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc3ByaW5nLyZn dDs8L2E+KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPkxhc3QgdXBkYXRlZDxz cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+MjAyMC0wNC0x NCAobGF0ZXN0IHJldmlzaW9uIDIwMjAtMDMtMjcpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+UmVwbGFjZXM8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PmRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmcgPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNy djYtbmV0d29yay1wcm9ncmFtbWluZy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZpbHNmaWxzLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmcvPC9hPiZndDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5TdHJlYW08c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPklFVEY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5JbnRlbmRl ZCBSRkMgc3RhdHVzPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj5Qcm9wb3NlZCBTdGFuZGFyZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPkZvcm1hdHM8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPiZuYnNwO3BsYWluIHRleHQgPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaWQvZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLTE1LnR4 dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3Jr LXByb2dyYW1taW5nLTE1LnR4dDwvYT4mZ3Q7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwO3htbCA8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGR
<= div dir=3D"ltr">

Gyan= =C2=A0 Mishra

Network Engineering & Technology= =C2=A0

Verizon=C2=A0

Silver Spring, MD 20= 904

Phone: 301 502-1347

<= font size=3D"1" color=3D"#000000" face=3D"georgia, serif">Email: gyan.s.mishra@verizon.= com



Fixed the typo in the RFC number below.
Any thoughts? Some quick changes from my side sho= ws connection setup times for client to accessory acting as WiFi AP over v6= LLA that gets triggered right after=C2=A0joining it, from ~2 seconds to a = tens of milliseconds.=C2=A0

On Sun, May 3, 2020 at 12:38 AM prabhakar lakher= a <prab= hakar.lakhera@gmail.com> wrote:
I have to correct myself here.=

RFC 4861 does mandate sending SLLAO=C2=A0for mult= icast NS (which would be the case for address resolution here) and that doe= s make sense.
While it is definitely desired, I am not sure how c= an we resolve the stated issue below without relaxing that requirement.

One could=C2=A0modify the requirement that multicast = NS with source that is preferred MUST send SLLAO.
And=C2=A0RFC 7527=C2=A04429 could relax the requirement and allow for sen= ding multicast NS for address resolution with optimistic address which MUST= not include SLLAO.

It does imply that for the sce= nario below, responding to such multicast NS with an unicast NA would in tu= rn trigger another address resolution but that is not very different from w= hen unicast NS may miss SLLAO and the target doesn't have NS's sour= ce entry in its neighbor cache.

It would still res= ult in establishing the data path faster than waiting for DAD to complete.<= /div>

I am not sure, how else it could be solved other t= han a more complicated work around of requiring such APs to advertise RA wi= th SLLAOs even when they are not providing any IPv6 kind of routing.
<= div>
On Tue, Apr 28, 2020 at 6:26 PM prabhakar lakhera <prabhakar.lakhera@gmail.com= > wrote:
=
Hi,

Wa= nted to check if this behavior outlined=C2=A0in RFC 7527 is too restrictive= .


Specifically:=

* (modifies section = 7.2.2) A node MUST NOT use an Optimistic Address as the source address of a Neighbor Solicitation.

The reasoning is detailed here:
=

<= /div>
" In order to avoid interference, it is important that an Optimis= tic=C2=A0Node does not send any = messages from an Optimistic Address
=C2=A0 that will=C2= =A0override its neighbors' N= eighbor Cache (NC) entries for the address=C2=A0it is trying to configure: doing so would disrupt the
=C2=A0 rightful owner=C2=A0of the address in the case of a collision."

It then goes on to list the following:

   * Never sending Neighbor Solicitations from an Optimistic=
 Address.
     NSes include a Source Link-Layer Address Option (SLLAO), which
     may cause Neighbor Cache disruption.  NSes sent as part of DAD
     are sent from the unspecified address, without a SLLAO.

That seems somewhat=
 limiting.

Take the scenario of a=
 client device connecting to another device that acts as an Access point wi=
thout
really provid=
ing routing (say a thermal camera device, android auto/car play head unit o=
r some other smart device).

Right=
 now, this would be the sequence:

1. Interface comes up
2. Client attached to device acting as WiFi access point.
<= pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef= ore:page">3. Both sides configure LLA pret= ty quickly.
4. Clie=
nt uses multicast service discovery to get the LLA endpoint of the device.<=
/font>
5. Client attempts =
connect to the device's endpoint. Optimistic DAD implies, the address c=
an be used.
6. Outg=
oing TCP SYN from client will trigger address resolution, and it will be qu=
eued pending address resolution completion.
7. Even though client LLA is optimistic, because i=
t is the only address available and the device isn't sending RA with SL=
LAO or NS,
    the =
neighbor cache entry at Client for Device would stay in INCOMPLETE state an=
d no NS will be sent out from client, till address
    moves from optimistic to preferred.
8. 7 Implies a wait =
time of DAD attempts * DAD interval

That runs in seconds and that delay is visible to user.

Given that sou=
rce link layer information is optional in NS, wouldn't just mandating t=
hat SLLAO doesn't get sent in NS from client,
be enough to not cause any disruptions rathe=
r than not allowing NS to be sent at all?

=
Or may be I am missing somethin=
g here. Looking forward to hear some feedback on this.

Thanks!

Pr=
abhakar

--000000000000ff4dcc05a51e2ed6-- From nobody Fri May 8 03:15:47 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E143A099F for ; Fri, 8 May 2020 03:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RiAvw5k2aqm for ; Fri, 8 May 2020 03:15:38 -0700 (PDT) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673E43A0992 for <6man@ietf.org>; Fri, 8 May 2020 03:15:38 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp2059.outbound.protection.outlook.com [104.47.0.59]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-83-9sBBJFHJOGufXtmlwznZBw-1; Fri, 08 May 2020 11:15:32 +0100 X-MC-Unique: 9sBBJFHJOGufXtmlwznZBw-1 Received: from AM6PR03MB5047.eurprd03.prod.outlook.com (2603:10a6:20b:89::13) by AM6PR03MB3607.eurprd03.prod.outlook.com (2603:10a6:209:34::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.28; Fri, 8 May 2020 10:15:31 +0000 Received: from AM6PR03MB5047.eurprd03.prod.outlook.com ([fe80::8081:95b4:8a9d:e05d]) by AM6PR03MB5047.eurprd03.prod.outlook.com ([fe80::8081:95b4:8a9d:e05d%6]) with mapi id 15.20.2979.030; Fri, 8 May 2020 10:15:30 +0000 From: Andrew Alston To: Ron Bonica , "Darren Dukes (ddukes)" , Krzysztof Szarkowicz CC: 6man <6man@ietf.org> Subject: RE: Routing Header Insertion Thread-Topic: Routing Header Insertion Thread-Index: AQHWI58t0MrEgFbBRG+Eev5I1WHYlaia/q4AgAHXnICAAAry0IABGRow Date: Fri, 8 May 2020 10:15:30 +0000 Message-ID: References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> 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_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-05-07T17:26:09.7979291Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=0dc8cb13-b1cd-4358-b2cf-2c6a0b8836d2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic x-originating-ip: [2c0f:fe40:3:2:8127:1b33:8af4:f0ec] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cdbf12a8-6e0b-4a4b-7cec-08d7f338bcec x-ms-traffictypediagnostic: AM6PR03MB3607: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 039735BC4E x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eAHzcoiFFsgw3H+jNMQXqfIHttYsDAU/wAmXiPxnfKo/erenjVrWVJ1rshclhMmTNmmzPyeNsDVAQxtWkFslvtab43PPqXWtALpIW+72ImU7t4y1tGZSj2ibhxxutrBDCs1v/SRWzMskHmQwAs9hIdIkmmWuxpbcijD1UOT1H4lj/Bosp0oUaQYk8w3SPpa/0ULNjivI1pcUoNHjv3m8E+OnflKEGtSLvzObtLKLGqcnlVlzWt5d0a2a6o3kKGQzvVRlBh2Fp62WqQc6KsFlubVMMvwaN97aKWHMlr/xzsHWgInIKOnV/wwbkLCSg5Z2IZPElVkamwttvgISz84xXJ3j4QCRySWUb5/oMIG5BLMlclc8yYxl8njXuWLbEK0Efxp7yzYfCunkqDy8RKoOhyqq0CU6NtseCxkboFRRg9df8b0EnP/NDFb2l6hJgdMstOeB2jxdWibbcm11uRrzlq4aGz32fBwZQu+gUCYkIXEDF3tNFgASSSia5xNq7ScGGnR6IVNZ+pwlloTSh/nlLOku6Hj83UG+FkQKyvJA4wOxLdeS1QyU6QkPPHCPYyFGuTQGb98qxWPdglKzFRC5J5GS1LEonKLkkAIajduVXp0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR03MB5047.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(136003)(346002)(376002)(366004)(33430700001)(33440700001)(64756008)(8676002)(52536014)(53546011)(5660300002)(8936002)(4326008)(7696005)(6506007)(83300400001)(83080400001)(7116003)(83290400001)(83280400001)(83310400001)(83320400001)(55016002)(2906002)(110136005)(3480700007)(166002)(478600001)(66574014)(966005)(316002)(76116006)(66446008)(66556008)(86362001)(186003)(71200400001)(9686003)(33656002)(66476007)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: XEBYy+I+1zZmV62+hZgo0Gx77ravGXNc9aGseeTU26EaXhzMQ+RAWS0vNcHp4LVb65oDc9kC4DjzIaSfwbXIswuHR8WWlkDZP5jKxg+PbvbftP/s5yfyup9UyX57DAYHasvLk58wiauJLViRxPA4yckkJUw2QvFZZFfkzpD2Rnz/LtLNj5FOt2cKjPxzhsmBlOfmWWN0qMHQY7FpR+/ZuMOEyrN0CBJDuU5w10t0b4pnP5lwkDGRjQUcwbkwih/+VQ1y2FmeCxB5po6Nzy2o+BMkEdkpGMnKHiaPMT1U15CYIlqEJC5KCUL5YGZHlMGSWU7pxrzLFpUhoTdlL4fRn2dtzI9Uz1/8hOb7s012D1yyFV1DzJi1eYnfKsnBcSathozk+twmwIz2S/cQb5Uny/5mot150hDfbBzcBXtAMc4R85K+9YQgHPutnITdWjxmngC4+B7wc1x0ZYB2mE5yUDMgCrc1tx3Uyvy+fVdUZFKezAIT7uAew/C82S7NhY/V6LRCQrDvJrRT9S5o8y1oGuy/m+s5ddszetR5mfT7k5U= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdbf12a8-6e0b-4a4b-7cec-08d7f338bcec X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 10:15:30.8908 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LyMy2nlrsN/5ZpwUNOWcAUlugUjgbm3FGai467lZj2XfOXyY7Zl0MJyaPleda/jPDKu4coRuffqFMygtI50mehkuDj6RbIBj+V+a7KVyQMg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR03MB3607 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Type: multipart/alternative; boundary="_000_AM6PR03MB5047D06890AAC079AD2B8C39EEA20AM6PR03MB5047eurp_" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 10:15:45 -0000 --_000_AM6PR03MB5047D06890AAC079AD2B8C39EEA20AM6PR03MB5047eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I do find it kinda bizarre that one vendor or an individual would jump to a= conclusion and make statements about what another one desires - surely it = is up to the vendor that desires something to publicly state so and not for= someone else to make statements on their behalf? I mean - let's be clear - I have written a partial SRv6 / SRv6-NP implement= ation into our DPDK lab testing stack - I did it to verify certain things -= the only thing it further convinced me of is that I will never run this i= n production - in a million years - and I'd be rather concerned if someone = went out there and said on the basis of the fact that I chose to test somet= hing - I suddenly supported or liked it. What that's effectively saying is= - to test something is to support it - that's not the case. It's similar = to the line that I was given that because I signed a blue sheet in Singapor= e and didn't stand up at the microphone and publically object to something = at the time - some how my signature on the blue sheet indicated my acceptan= ce and support of the issue in question. (To quote that) PC2: The comment started because in the draft we had an example that was as= signing A:1::/32 as loopback interface for a router. This is wrong (prefix = length, documentation prefix,). This was fixed in revision 2 of the WG draft, published in September 19th 2= 019. The closure of this comment was presented by me personally in IETF Sin= gapore. Please refer to the slides. In Singapore you were present (signed b= lue sheet) and did not had any comment about such closure. This is interesting - so firstly - let me state that because I was present = in a meeting and signed a blue sheet to say I was there - in no way indicat= es that I forgo the right to object after the meeting - and last I checked,= signatures on a blue sheet are there to track attendance, not to track con= sensus. So - can I make a humble request that we let people speak for themselves ab= out what they actively support and want rather than trying to speak for oth= ers to bolster our case? Because if the case is so weak that we need to ma= ke claims on behalf of others - then there is no case at all. Thanks Andrew From: ipv6 On Behalf Of Ron Bonica Sent: Thursday, 7 May 2020 20:26 To: Darren Dukes (ddukes) ; Krzysztof = Szarkowicz Cc: 6man <6man@ietf.org> Subject: RE: Routing Header Insertion Darren, I would not infer that Juniper sees SRH insertion as desirable. Ron Juniper Business Use Only From: Darren Dukes (ddukes) > Sent: Thursday, May 7, 2020 12:44 PM To: Krzysztof Szarkowicz > Cc: Voyer, Daniel >; Ron = Bonica >; Eric Vyncke (evyn= cke) >; 6man <6man@ietf.org> Subject: Re: Routing Header Insertion [External Email. Be cautious of content] Krzysztof thanks for the link, to me it does seem that Juniper sees SRH ins= ertion for TILFA as desirable, as documented in draft-voyer-6man-extension-= header-insertion. So Dan, I think we can jump to that conclusion supported by 19 implementati= ons and 5 deployments as captured in draft-matsushima-spring-srv6-deploymen= t-status, including Juniper's. Darren On May 6, 2020, at 8:36 AM, Krzysztof Szarkowicz > wrote: Also, There is short video discussing SRv6 TI-LFA EANTC test: https://youtu.be/v9woK-7AiyA Thanks, Krzysztof On 2020 -May-06, at 14:09, Voyer, Daniel > wrote: Ron, yes - I echo Eric - all my respect. Ron, I for one, would jump to conclusion for that specific use case where i= nsertion is performed, and have the expected behaviour. This is the exact u= se case that was described over the years in this mailing list, Now, obviously, this use case is contain within the operator domain. I don'= t expect an operator to have "TI-LFA" on their peering links with other tra= nsit/operator. For people references, page 15 "TI-LFA over SRv6": http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDN= NFV2020-WhitePaper.pdf Thanks, dan From: ipv6 > on behalf = of "Eric Vyncke (evyncke)" > Date: Wednesday, May 6, 2020 at 7:08 AM To: Ron Bonica >, 6man <6man@ietf..org> Subject: [EXT]Re: Routing Header Insertion Ron, All my respect to you for this correction of yours. Regards -=E9ric PS: I was about to reply unicast to Ron but decided that Ron deserves some = public appreciation for his email. From: ipv6 > on behalf = of Ron Bonica > Date: Wednesday, 6 May 2020 at 02:52 To: 6man <6man@ietf.org> Subject: Routing Header Insertion Folks, My apologies to Zafar Ali. Reading through the EANTC report, it appears the= Juniper demonstration SRv6 Routing Header insertion to support TI-LFA. In = that respect, Zafar is correct. However, we should not jump to the conclusion that such behavior is desirab= le. Ron Juniper Business Use Only Juniper Business Use Only -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- Juniper Business Use Only --_000_AM6PR03MB5047D06890AAC079AD2B8C39EEA20AM6PR03MB5047eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I do find it kinda bizarre that one vendor or an individual would jum= p to a conclusion and make statements about what another one desires –= ; surely it is up to the vendor that desires something to publicly state so and not for someone else to make statements= on their behalf?

 

I mean – let’s be clear – I have written a partial = SRv6 / SRv6-NP implementation into our DPDK lab testing stack – I did= it to verify certain things – the only thing it further convinced me  of is that I will never run this in production – in a milli= on years – and I’d be rather concerned if someone went out ther= e and said on the basis of the fact that I chose to test something – = I suddenly supported or liked it.  What that’s effectively sayin= g is – to test something is to support it – that’s not the= case.  It’s similar to the line that I was given that because I= signed a blue sheet in Singapore and didn’t stand up at the micropho= ne and publically object to something at the time – some how my signa= ture on the blue sheet indicated my acceptance and support of the issue in ques= tion. 

 

(To quote that)

 

PC2: The comment started because in the draft we had an example that was a= ssigning A:1::/32 as loopback interface for a router. This is wrong (prefix= length, documentation prefix,).

This was fixed in revision 2 of the WG draft, published in September 19th 2019. The closure of this comment was presented by me personally= in IETF Singapore. Please refer to the slides. In Singapore you were present (signed blue sheet) and did not had = any comment about such closure.

 

 

This is interesting – so firstly – let me state that because I= was present in a meeting and signed a blue sheet to say I was there –= ; in no way indicates that I forgo the right to object after the meeting – and last I checked, signatures on a blue sheet are the= re to track attendance, not to track consensus.

 =

 

So – can I make a humble request that we let people speak for t= hemselves about what they actively support and want rather than trying to s= peak for others to bolster our case?  Because if the case is so weak that we need to make claims on behalf of others = 211; then there is no case at all.

 

Thanks

 

Andrew

 

 

 

 

 

From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Ron Bonica
Sent: Thursday, 7 May 2020 20:26
To: Darren Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.ietf.org>= ;; Krzysztof Szarkowicz <kszarkowicz@gmail.com>
Cc: 6man <6man@ietf.org>
Subject: RE: Routing Header Insertion

 

Da= rren,

 

I = would not infer that Juniper sees SRH insertion as desirable.

 

&n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;           &nbs= p;    Ron

 

 

 

Juniper Business= Use Only

From: Darren Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.iet= f.org>
Sent: Thursday, May 7, 2020 12:44 PM
To: Krzysztof Szarkowicz <kszarkowicz@gmail.com>
Cc: Voyer, Daniel <daniel= .voyer@bell.ca>; Ron Bonica <rbonica@juniper.net>; Eric Vyncke (evyncke) <evyncke@cisco.com>; 6man <6man@ietf.org>
Subject: Re: Routing Header Insertion

 

[External Email. Be cautious of content]

 

Krzysztof thanks for the link, to me it does seem that= Juniper sees SRH insertion for TILFA as desirable, as documented in draft-= voyer-6man-extension-header-insertion.

So Dan, I think we can jump to that conclusion supported by 19 impleme= ntations and 5 deployments as captured in draft-matsushima-spring-srv6= -deployment-status, including Juniper's.

Darren

 

On= May 6, 2020, at 8:36 AM, Krzysztof Szarkowicz <kszarkowicz@gmail.com> wrote:

 

Al= so,

 

Th= ere is short video discussing SRv6 TI-LFA EANTC test:

 

ht= tps://youtu.be/v9woK-7AiyA

 

Th= anks,

Kr= zysztof

 

On= 2020 -May-06, at 14:09, Voyer, Daniel <daniel.voyer@bell.ca> wrote:

 

Ro= n, yes – I echo Eric – all my respect.

&n= bsp;

Ro= n, I for one, would jump to conclusion for that specific use case where ins= ertion is performed, and have the expected behaviour. This is the exact use= case that was described over the years in this mailing list,

&n= bsp;

No= w, obviously, this use case is contain within the operator domain. I don= 217;t expect an operator to have “TI-LFA” on their peering link= s with other transit/operator.

&n= bsp;

Fo= r people references, page 15 “TI-LFA over SRv6”:

http://www.eantc.de/fileadmin/eantc/downloads/events/= MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf

&n= bsp;

Th= anks,

da= n

&n= bsp;

From:&nbs= p;ipv6 &l= t;ip= v6-bounces@ietf.org> on behalf of "Eric Vyncke (evyncke)" <evyncke=3D40= cisco.com@dmarc.ietf.org>
Date: Wednesday, M= ay 6, 2020 at 7:08 AM
To: Ron Bonica <= ;rbonica=3D40juniper.net@dmarc.ietf.org>, 6man &= lt;6man@ietf= ..org>
Subject: [EXT]Re: = Routing Header Insertion

&n= bsp;

Ron,<= /span>

 = ;

Al= l my respect to you for this correction of yours.

&n= bsp;

Re= gards

&n= bsp;

-= =E9ric

&n= bsp;

PS= : I was about to reply unicast to Ron but decided that Ron deserves some pu= blic appreciation for his email.

&n= bsp;

From:&nbs= p;ipv6 &l= t;ip= v6-bounces@ietf.org> on behalf of Ron Bonica <rbonica=3D40juniper.net@dmarc.iet= f.org>
Date: Wednesday, 6= May 2020 at 02:52
To: 6man <6man@ietf.org>
Subject: Routing H= eader Insertion

&n= bsp;

Fo= lks,

&n= bsp;

My= apologies to Zafar Ali. Reading through the EANTC report, it appears the J= uniper demonstration SRv6 Routing Header insertion to support TI-LFA. In th= at respect, Zafar is correct.

&n= bsp;

Ho= wever, we should not jump to the conclusion that such behavior is desirable= .

&n= bsp;

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        Ron

&n= bsp;

&n= bsp;

Juniper Business Use Only

&n= bsp;

Juniper Business Use Only

------= --------------------------------------------------------------
IETF IPv6 working group mailing list

Administrative Requests: =
https://www.ietf.= org/mailman/listinfo/ipv6

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

 

--= ------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

 

 

Juniper Business= Use Only

--_000_AM6PR03MB5047D06890AAC079AD2B8C39EEA20AM6PR03MB5047eurp_-- From nobody Fri May 8 03:33:40 2020 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07F03A09C4 for ; Fri, 8 May 2020 03:33:36 -0700 (PDT) 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, 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=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMoj_oKL4jJi for ; Fri, 8 May 2020 03:33:33 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8138D3A09CD for <6man@ietf.org>; Fri, 8 May 2020 03:33:33 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id y24so901154edo.0 for <6man@ietf.org>; Fri, 08 May 2020 03:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=seTlXqyf7r6rSbIbr4vR8IbxbUM0CmaEf0g2HW+WpW0=; b=SzeSNp44ccHCxrFk82PvMCiFOgHU8swUtRysnwju08Cx/WoqHW+dBQ9qWUcdYitA8c Hg3+iq7NawNpwvf1PnCWHGYHjWw3m3oIXD8ZAEBsN8/BycYQxer+FG3wJ6ZBYkA81hec GoYKbSaQOfj/Oa30HWBDb3V6B1Bi+zi51wmgvf99TXa0Qa4xA0br+tA/h/A6zblLlppt +Llgg4dha9yT31lcYKQWvWDFOcxqzzBKzmc6VntCAefzMg36pvYqf5/rSsfuGAlgWiS7 zgp7ImEc5eAlb0pLYQyr2rsogytXYG7t19gitO9QANTYtaBQaM2zqXCNLDd0nVB+L9ZU JufA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=seTlXqyf7r6rSbIbr4vR8IbxbUM0CmaEf0g2HW+WpW0=; b=r6E1iSddOmK7iXoaaqrGpRKjwzCiweJ1zqyA7HaKSn8cDq9Vit37xnHJw18B/PJKrV qi/I6TMhSgIpUcIzD+Sy9EkTReA1NB3ZqcVR1EMMVonIx/y+QZHM/1bKhH9Gq/SwwlYc p0NaztuBQ++1wqKVfY96E4jN6rvf0OBeEibpXbN7BzYXzu0mqr8vwa9yqvj7zO15ThC2 OV7oewyY1cPl/HYS7fZ841w7FxHEEF1BRpoXqE0mIoUErC+lLChSrNsAZv/p/FFEdoCw AJ63h8Vm1Kh/BPuHipQnBMoCloF3/7jPG5bqx/lE2SFn2xXGX2EdJFIskCJCy+Trt9hs smVg== X-Gm-Message-State: AGi0Pub3x4ztgpanQ4T5X09I+Gqex2mXBgcUVZb+5hkLLykbFrxuvJvD E1zaAzY5PnDqxjYxZM27QyfT0CUp2vX4o5zxPPe3TQ== X-Google-Smtp-Source: APiQypJD3QFRbk3BjVlTkkMRaPr5CeItEQwasYToX2wEoBNIRde/psIAV1YaNIMpy2E02iNeJQxEaDpw163Dc3ilMDY= X-Received: by 2002:aa7:c5d1:: with SMTP id h17mr1514326eds.109.1588934011459; Fri, 08 May 2020 03:33:31 -0700 (PDT) MIME-Version: 1.0 References: <497430AB-1840-4320-991F-B4906607033E@gmail.com> <6E089E7E-4D09-4704-A3A9-1A3878FC3786@cisco.com> In-Reply-To: From: Robert Raszuk Date: Fri, 8 May 2020 12:33:22 +0200 Message-ID: Subject: Re: Routing Header Insertion To: Andrew Alston Cc: Ron Bonica , "Darren Dukes (ddukes)" , Krzysztof Szarkowicz , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000532d6705a5208766" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 10:33:38 -0000 --000000000000532d6705a5208766 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Andrew, I don't think the point is on what one vendor desires or likes. The point is that they internally committed development resources to deliver this functionality. They also asked one of their top talented TME Krzysiek to go and demo it. It carries a message. And all Zafar and others did was just sharing that message. It really does not matter that much Ron himself or on behalf of his company can jump on the lists stating that he does not like it. Even if Juniper marketing will not push it - even if they develop next cartoon mocking it - they will still likely check mark support tag on the RFPs. *All that proves that SRH insertion is a useful feature to customers.* And that's all what matters to some IETF decisions as part of that is community needs and support for extensions under standardization. Best, Robert. On Fri, May 8, 2020 at 12:16 PM Andrew Alston < Andrew.Alston@liquidtelecom.com> wrote: > I do find it kinda bizarre that one vendor or an individual would jump to > a conclusion and make statements about what another one desires =E2=80=93= surely it > is up to the vendor that desires something to publicly state so and not f= or > someone else to make statements on their behalf? > > > > I mean =E2=80=93 let=E2=80=99s be clear =E2=80=93 I have written a partia= l SRv6 / SRv6-NP > implementation into our DPDK lab testing stack =E2=80=93 I did it to veri= fy certain > things =E2=80=93 the only thing it further convinced me of is that I wil= l never > run this in production =E2=80=93 in a million years =E2=80=93 and I=E2=80= =99d be rather concerned > if someone went out there and said on the basis of the fact that I chose = to > test something =E2=80=93 I suddenly supported or liked it. What that=E2= =80=99s effectively > saying is =E2=80=93 to test something is to support it =E2=80=93 that=E2= =80=99s not the case. It=E2=80=99s > similar to the line that I was given that because I signed a blue sheet i= n > Singapore and didn=E2=80=99t stand up at the microphone and publically ob= ject to > something at the time =E2=80=93 some how my signature on the blue sheet i= ndicated > my acceptance and support of the issue in question. > > > > (To quote that) > > > > *PC2: The comment started because in the draft we had an example that was > assigning A:1::/32 as loopback interface for a router. This is wrong > (prefix length, documentation prefix,).* > > *This was fixed in revision 2 of the WG draft, published in September 19t= h > 2019. The closure of this comment was presented by me personally in IETF > Singapore. Please refer to the slides. In Singapore you were present > (signed blue sheet) and did not had any comment about such closure.* > > > > > > *This is interesting =E2=80=93 so firstly =E2=80=93 let me state that bec= ause I was > present in a meeting and signed a blue sheet to say I was there =E2=80=93= in no way > indicates that I forgo the right to object after the meeting =E2=80=93 an= d last I > checked, signatures on a blue sheet are there to track attendance, not to > track consensus.* > > > > > > So =E2=80=93 can I make a humble request that we let people speak for the= mselves > about what they actively support and want rather than trying to speak for > others to bolster our case? Because if the case is so weak that we need = to > make claims on behalf of others =E2=80=93 then there is no case at all. > > > > Thanks > > > > Andrew > --000000000000532d6705a5208766 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hey Andrew,
I don't think the point is on what one vendor desires = or likes. The point is that they internally committed=C2=A0development reso= urces to deliver this functionality. They also asked one of their top talen= ted TME=C2=A0Krzysiek to go and demo it. It carries a message. And all Zafa= r and others did was just sharing that message.=C2=A0

<= div>It really does not matter that much Ron himself or on behalf of his com= pany can jump on the lists stating that he=C2=A0does not like=C2=A0it. Even= if Juniper marketing will not push it - even if they=C2=A0develop=C2=A0nex= t cartoon mocking=C2=A0it - they will still likely check mark support tag o= n the RFPs.=C2=A0

All that proves that SRH inse= rtion is a useful feature to=C2=A0customers. And that's all what ma= tters to some IETF decisions as part of that is community needs and support= for extensions under standardization.

Best,
=
Robert.