Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

James Guichard <james.n.guichard@futurewei.com> Thu, 12 March 2020 15:33 UTC

Return-Path: <james.n.guichard@futurewei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0563A0C7F; Thu, 12 Mar 2020 08:33:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt-5V5aPMOc2; Thu, 12 Mar 2020 08:33:40 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2098.outbound.protection.outlook.com [40.107.220.98]) (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 3E9AB3A0C54; Thu, 12 Mar 2020 08:33:39 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XgNC6UVpEZDFc1xBFsA9WAjSdo69uSJmJEpHoT9BF5Xy3ZobJagsHfxrLxjRqveFY+FFIZhWeGVY/JQZrZAOAX9UpWMncFdkployapMdBkmN1/kf3PRusKDDstlJaP5F3/4aBYDy8B+4ucHifDRNZDs5Z5+cCS9EnedPBe4VDO84UYXhg1kagfMbgfPGVvLjHAQFcM8VKV4yC1R74s+7BT8F4yLJwqrffqceP1bNbe4HJjfI+lmIp7AqwaK0dsoLYQgV4CA013sCIWLxnt/MbTkua0rxUL/0glxfRqY0mRvPadXNOGfIAKMJhnpdd2jU3SJc/ahe82T39p8O9HDtcg==
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=Z9+Y442Cak6d2lLt49Q5LvsuMC2nXehz2YDpR540QeQ=; b=OfLzrGpWYgS6D18/enBw4bKccQ3NKinozAF36MpEOALCcssLnMGyl6B07vJLeZIfdZ3kyTBvHTgiWj225n+kLwbNEL//TIRHJaX64+TRqpGMHMekpA/s2Jy9lMLgzhNB3e1eXa57SyE8ism6qHANki6HVmEPbfLhbw9Z4uMTSi2/0KmUBYspCmw4B7WiGw1RGSocshpi6U0edR2Jjtre4WQfgB1EjkAw4h34IXvdCWz9f8Ul157uOTefcc1CIKrRiJ56CRg/Vji002N1A0upss53xHgAuh9puGIrYK0gtW+JJFNB3ZthUH7NNZN5GLJX9732itiylrMioXNYSaDfgg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=Z9+Y442Cak6d2lLt49Q5LvsuMC2nXehz2YDpR540QeQ=; b=kV/QdWnsNB355r7dI0WA0Uouw2Wyam43aIYeRvnhdSv/GQNN9nOBfnfOD5HyM7RR6Gb07dL20nN4i0g3Ac3DmYKZyfdymBIA1tn0TX3t76sXUdEn3K9CvisJQxUU8Hwtks3g6+VCzT8fDOPlps54e0vZSqE1slMLFgRS5vUIkm8=
Received: from DM6PR13MB3066.namprd13.prod.outlook.com (2603:10b6:5:19d::18) by DM6PR13MB3530.namprd13.prod.outlook.com (2603:10b6:5:148::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.8; Thu, 12 Mar 2020 15:33:37 +0000
Received: from DM6PR13MB3066.namprd13.prod.outlook.com ([fe80::14f3:6cb8:b9da:446]) by DM6PR13MB3066.namprd13.prod.outlook.com ([fe80::14f3:6cb8:b9da:446%5]) with mapi id 15.20.2814.007; Thu, 12 Mar 2020 15:33:37 +0000
From: James Guichard <james.n.guichard@futurewei.com>
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "Darren Dukes (ddukes)" <ddukes@cisco.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
CC: "spring@ietf.org" <spring@ietf.org>, 6man WG <ipv6@ietf.org>
Thread-Topic: Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
Thread-Index: AQHV+Efw2klvaTQoT0qL3DKKC//ouKhFFUnQ
Date: Thu, 12 Mar 2020 15:33:37 +0000
Message-ID: <DM6PR13MB30660BB97B5D0EDD52F43A96D2FD0@DM6PR13MB3066.namprd13.prod.outlook.com>
References: <4F4FF5EC-690F-4C09-9101-98AB2DDFDE0C@liquidtelecom.com> <a38c3197-2513-4af6-cb4f-a0a96c082cb9@gmail.com> <DBBPR03MB541585909C4D92325A69F1EFEEFD0@DBBPR03MB5415.eurprd03.prod.outlook.com>
In-Reply-To: <DBBPR03MB541585909C4D92325A69F1EFEEFD0@DBBPR03MB5415.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=james.n.guichard@futurewei.com;
x-originating-ip: [47.14.47.233]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 597c966d-0b14-4f1c-da2d-08d7c69abbc4
x-ms-traffictypediagnostic: DM6PR13MB3530:
x-microsoft-antispam-prvs: <DM6PR13MB35309562E15348557230546FD2FD0@DM6PR13MB3530.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0340850FCD
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(396003)(39840400004)(346002)(376002)(136003)(199004)(8936002)(186003)(86362001)(7696005)(33656002)(316002)(81156014)(81166006)(54906003)(110136005)(4326008)(8676002)(5660300002)(66476007)(66556008)(478600001)(966005)(66946007)(64756008)(2906002)(9686003)(66446008)(9326002)(55016002)(76116006)(26005)(52536014)(6506007)(71200400001)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR13MB3530; H:DM6PR13MB3066.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: thRQb68yTVUwiI4FABMgc+NxbPWu3/1iWm9szGH9Ik8mcMcsQRu+0ptf4gKEOvaZOLOnqclBzfvbVOKKIx/HnPOGTHrsuUYQSdYPOLKopSV2Fnulhzlsfu4A3LfE46+zyliKuYxDFH08LSVN0gBN+wlZmwEFDjINS31Enym9dl7wTdE6AU7S7HVhw0ksnOvUVA/bLYLl01dVjY0HSKOuQKtXrI8cYKPEC8q68tuH5syZpww3urdWvFRbFbZjQ8sh+C8s4wk7bFKiLwMs8LmjGVQTCvG8ud15Gd5HKLokYNxfAd5K5LTvGIdRMmoh7AlVG5DH1xfB/ZKFr1dUqnFwVRScozd5T6kWatkJe8XyaWY/xAgPAZPE3DzaP7yqu73VOEJP9oStFMv6O+2HfOQCnKFphgL1OeETauqO3AGhi8ZaQ1yqPh6GtRvyo4xn3Ft0RjJ9Qi2P0/6HiZMYAZoOEgJrbpo+oN8/ZBjNNVzh5ocUJ62jQHeAQLVykzjt49v/yo2TUCZaPO/CSCNKGqQ7NQ==
x-ms-exchange-antispam-messagedata: jJVUiqpPkULH43UR0A/HK471OJbq+WwhOfPC8M1lbF4H2bpUZeMav+p+fkXKEP1XNEZWjqeaFAQ7pggNgfqtGIdCniLmzYncPv5+S1X4S2DF8qdl4V+0Y0QXkCHymcn2jvjHLnUnmMPY9NfBLWoQ4A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR13MB30660BB97B5D0EDD52F43A96D2FD0DM6PR13MB3066namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 597c966d-0b14-4f1c-da2d-08d7c69abbc4
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 15:33:37.2728 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: P70JG3LZ+CgvFZVdLVNBk2p/ALcIQGfIhLcfnJHoKtyrlckov9oJaQRzr5pR/5dPIYr/1wDRmy0ssWkDDftmbQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB3530
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/l_8H5IPUb8HfhxrlZroibVfDhmA>
Subject: Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2020 15:33:52 -0000

Hi Andrew,

Given RFC2460 definition of a link I am wondering which “link” a loopback interface attaches to in your opinion?

Jim



From: spring <spring-bounces@ietf.org> On Behalf Of Andrew Alston
Sent: Thursday, March 12, 2020 4:26 AM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>; Darren Dukes (ddukes) <ddukes@cisco.com>; Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: spring@ietf.org; 6man WG <ipv6@ietf.org>
Subject: Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Brian,

Let me clarify a few things – for my own understanding – I am happy to be wrong here, and if I am just let me know (while what I am writing may come across as statements, it was easiest to write that way, consider the statements clarification questions) –

Firstly – let us consider the RFC8402 argument for a second – though I think we should probably consider this separately.  In reference to RFC8402 this draft states – in section 3:

When an SRv6 SID is in the Destination Address field of an IPv6
   header of a packet, it is routed through an IPv6 network as an IPv6
   address.

So – we establish that indeed – SRv6 SID’s are IPv6 addresses – there is no two ways about it – they go into the destination field.  This is contrary to what Robert argued in an email found at https://mailarchive.ietf.org/arch/msg/spring/u1AzYFpDe-AhIxXdih2BEIz65Bk/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2Fu1AzYFpDe-AhIxXdih2BEIz65Bk%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932632328&sdata=kN2%2FKe5EHt1bWtcK9f0zQq07mMLQVK4HIZ5spUNEHzY%3D&reserved=0>

Now, lets look at this draft specifically in reference to RFC4291.

Section 2 of RFC4291 states that IPv6 addresses are identifiers for interfaces and sets of interfaces – where an interface is defined in RFC2460 as a “node’s attachment to a link”.  This document creates SID’s that have no binding to any interface.  Section 3 of the NP draft explicitly refers to lookups that lookup SID’s (which we have already established are addresses) that have no interface bindings.

In section 3.1 – this talks about the Locator – this is entirely compliant with section 2.5 of RFC4291 – however – the function and arguments section of this – have no relation to interface ID’s – it is debatable if this is as a result of problems in RFC8402 or indeed, potentially both drafts – since it is this document that explicitly creates these function and argument sections independently of RFC8402 in section 3.1.

Indeed RFC3587 states in section 3:


[ARCH] also requires that all unicast addresses, except those that

   start with binary value 000, have Interface IDs that are 64 bits long

   and to be constructed in Modified EUI-64 format.  The format of

   global unicast address in this case is:


I fail to see how defining a function and arguments in the way this document describes are compliant with this.  Now, it can also be argued that there are many implementations that violate these specifications – Linux allows you to bind entire /64s to loopback addresses, however, I would argue that it is a very different case for an implementation to violate the specification as for an RFC to violate the specification and make it into a standard.

I will also note and acknowledge that some may think that I am being pretty pedantic here – but considering the context and the claims floating around about what other RFC’s say and don’t say – perhaps its time to start examining this whole thing with a fine tooth comb so that we can end up with a better result that works for everyone and doesn’t lead to unintended consequences.

Thanks

Andrew



From: Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>
Sent: Thursday, 12 March 2020 00:30
To: Andrew Alston <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>>; Darren Dukes (ddukes) <ddukes@cisco.com<mailto:ddukes@cisco.com>>; Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org>>
Subject: Re: Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

On 12-Mar-20 09:53, Andrew Alston wrote:
> Hi Spring WG
>
>
>
> On the basis of the below – I must conclude that the issues relating the SID/IPv6 semantics have indeed not been dealt with by the spring working group in the context of the network programming draft – and I would now like to raise those issues in the context of that draft – and the fact that draft-ietf-spring-network-programming violates the address semantic specifications of RFC4291.

I really think that this is subsidiary to RFC 8402 (a Proposed Standard):

SR can be applied to the IPv6 architecture with a new type of routing
header called the SR Header (SRH) [IPv6-SRH]. An instruction is
associated with a segment and encoded as an IPv6 address. An SRv6
segment is also called an SRv6 SID. An SR Policy is instantiated as
an ordered list of SRv6 SIDs in the routing header.

I don't see anything in the SRH draft or the network-programming draft
that is not within that definition. Whether RFC 8402 contravenes RFC 4291
is worth discussing, I guess. The latter says:

IPv6 addresses of all types are assigned to interfaces, not nodes.
An IPv6 unicast address refers to a single interface. Since each
interface belongs to a single node, any of that node's interfaces'
unicast addresses may be used as an identifier for the node.

However, I can't find anything in RFC 4291 that forbids addresses
having semantic meanings rather than being pure locators. It goes
against one of my design prejudices, but I can't find anything
resembling "Encoding semantics in address bits considered harmful"
in the RFCs.

In reality, there are lots of operational practices that amount to
giving semantic meanings to address bits.

Brian

>
>
>
> Can we please have a proper discussion on this
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From: *"Darren Dukes (ddukes)" <ddukes@cisco.com<mailto:ddukes@cisco.com>>
> *Date: *Wednesday, 11 March 2020 at 22:03
> *To: *Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>
> *Cc: *Andrew Alston <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>>, 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org>>
> *Subject: *Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
>
>
>
> Hi Ron, I made no comment in this thread on draft-ietf-spring-network-programming.
>
>
>
> Darren
>
>
>
> On Mar 11, 2020, at 2:55 PM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org <mailto:rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org%20%3cmailto:rbonica=40juniper.net@dmarc.ietf.org>>> wrote:
>
>
>
> Darren,
>
>
>
> Didn’t we agree to close issue 66 because draft-ietf-6man-segment-routing header contains no text regarding SID/IPv6 address semantics. If that’s the case, how can you say that closing issue 66 implies WG consensus around SID/IPv6 address semantic proposed in draft-ietf-6man-network-programming?
>
>
>
>                                                                                        Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* ipv6 <ipv6-bounces@ietf.org <mailto:ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org%20%3cmailto:ipv6-bounces@ietf.org>>> *On Behalf Of *Darren Dukes (ddukes)
> *Sent:* Tuesday, March 10, 2020 12:07 PM
> *To:* EXT-Andrew.Alston@liquidtelecom.com<mailto:EXT-Andrew.Alston@liquidtelecom.com> <mailto:EXT-Andrew.Alston@liquidtelecom.com> <Andrew.Alston@liquidtelecom.com <mailto:Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com%20%3cmailto:Andrew.Alston@liquidtelecom.com>>>
> *Cc:* 6man WG <ipv6@ietf.org <mailto:ipv6@ietf.org<mailto:ipv6@ietf.org%20%3cmailto:ipv6@ietf.org>>>
> *Subject:* Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
>
>
>
> Hi Andrew please see issue #66 for the closure record.
>
>
>
> https://trac.ietf.org/trac/6man/ticket/66<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2F6man%2Fticket%2F66&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932632328&sdata=QkZQTC9gfA7bjmANWqUIhQk4%2Fr5ECkz1hXkUbIMeHxw%3D&reserved=0> <https://urldefense.com/v3/__https:/trac.ietf.org/trac/6man/ticket/66__;!!NEt6yMaO-gk!RN-QFuaCraX6vU74Vusek5FlDyBGgfC2Teh1Vz40nw0PBhWdPtA-SA3t_rxaFg4_$<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftrac.ietf.org%2Ftrac%2F6man%2Fticket%2F66__%3B!!NEt6yMaO-gk!RN-QFuaCraX6vU74Vusek5FlDyBGgfC2Teh1Vz40nw0PBhWdPtA-SA3t_rxaFg4_%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932642321&sdata=KAJ6gn4hxCzDjblX8IigFrkB2J8uIz%2BesLVfPWqTXqk%3D&reserved=0>>
>
>
>
> Darren
>
>
>
> On Mar 9, 2020, at 3:18 PM, Andrew Alston <Andrew.Alston@liquidtelecom.com <mailto:Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com%20%3cmailto:Andrew.Alston@liquidtelecom.com>>> wrote:
>
>
>
> Hi Darren
>
>
>
> >  Hi Mark, the working group discussed the
>
>  > association with RFC4291 and closed it with
>
>  > the text in the document.
>
>
>
> Can we get a reference to these discussions please - would just be useful to back and refresh memories and wasn’t able to find them
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org<mailto:ipv6@ietf.org>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C337d560cf26a4d951a1a08d7c65f1100%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637195983932652318&sdata=9pahh101WJHVw5AQrT8lBMawkyZzHXOsVvK5VIk%2B82A%3D&reserved=0>
> --------------------------------------------------------------------
>