Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B308C120802 for ; Tue, 9 Jul 2019 10:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 zalRFjO50F74 for ; Tue, 9 Jul 2019 10:22:40 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CE9120807 for ; Tue, 9 Jul 2019 10:22:27 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id s145so13050009qke.7 for ; Tue, 09 Jul 2019 10:22:27 -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=qGFpvIR6PB3/zsAt93WZgYrnLUBs3YWIOWMnMc2r1Ks=; b=NC8jXacfmZq4c8kWnMGXSoNHXYAyLnNMjbHz4BrW9rIToATU8/D1A4JeVnPGYsqGEf 2u48mMKlrZX+a/TQQOxuCUMksa0cXpUfSNoKWtNSqSbnShOIZ8TE2JdbrRSmmRV/fdew esfpKGUvRuJ+3sG8dPss6eP6YqedRApxUDrOLmDoguvwKIBqoQz2TnvYgSUZ6r6h3Igi LjnXKL7gPV4bi4l13sHX4LzTPLJsGxmnw7gJzm7Zd8N58wXYERwhKm6JpaqrcO8T7zW1 ToQa+zdvRYDpcUXFRI+KfIfRTMVQjAF20QvGExzPb95z3FCZ/xBTuYL7R7VIF/T9MQbW U0wQ== 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=qGFpvIR6PB3/zsAt93WZgYrnLUBs3YWIOWMnMc2r1Ks=; b=W1QrY9HyNCKlud3u3ldUz0oEMSN49SErsZy9l0CrUW3SlNR0nFpySK64fU1Sq4XaPH kH2vXBg2TgUikG9I4gOoEVmc2CNakCDwViaTpmgm62VUN/cDA5uLyrUqLKMkDj518WnK 9MzzA2Wml9Cjwj8IiPJCpTiIJ4PaSOLZn8/ElEWwC39U+n+qjkv7KVXgJavJWT2SEAph cYN1tB4rblY0WFAz2gqiyNStaAKRs9ntp0ihwdqE/Zr86b+/goBM9+mnmDEq3f+OmW79 /rojS+6mTId+5/ne6a3KUlvN7U2IMgM1ELCNA3884v/8ne6CeFcjfScQ6A0kr4NnUiVI xjMA== X-Gm-Message-State: APjAAAXSzZfbXnNCtQr3kfGa2BMXX8zsQ7D6aYcCGyQ/ZJo9cFs6xMHj CVQ1jPPfRzNslCzNOi5pUW6CngDR5Suw0+E6GP6Gkg== X-Google-Smtp-Source: APXvYqwC+i5rlUTCEHYSv7yGkWZSWE1fTtXvGCOTiJfixLRPMbjeSgB0sfi0fBDqs5Zh2jFLkHWl+uL5R11EMpovV7Y= X-Received: by 2002:ae9:e64d:: with SMTP id x13mr18607483qkl.445.1562692946674; Tue, 09 Jul 2019 10:22:26 -0700 (PDT) MIME-Version: 1.0 References: <156258437287.1059.3258045720075872864@ietfa.amsl.com> <76CD132C3ADEF848BD84D028D243C927CCEF5243@NKGEML515-MBS.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927CCEF5243@NKGEML515-MBS.china.huawei.com> From: Robert Raszuk Date: Tue, 9 Jul 2019 19:22:16 +0200 Message-ID: To: "Dongjie (Jimmy)" Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Zhuangshunwan , "idr@ietf. org" Content-Type: multipart/alternative; boundary="000000000000fad973058d42cd11" Archived-At: Subject: Re: [Idr] I-D Action: draft-dong-idr-node-target-ext-comm-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 17:22:44 -0000 --000000000000fad973058d42cd11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jie, I think you are underestimating the effort to implement it correctly on the RRs :) Two clarifications to my points below: > If one Update carries both RT and Node Target, then both rules would be used > separately to determine how to send and receive the Update. It is not about if those are used separately or together ... this is implementation detail. What however matters in the spec is clear articulation if update needs to be sent when RTC is asking for it yet Node Target does not list a given peer (and vice-versa). > [Jie] I don=E2=80=99t quite get your question here. The list of Node Targ= et extended communities > is not be modified by a route reflector unless a local address matches one of the node > target. As discussed above, the node target which identifies a peer node will not be removed by the RR. Yes I am pointing out the "unless" situation. When interface goes down to the peer you have sent it to you need to now resend that subset of updates with modified Ext Community Attribute to other peers. In general the draft does not even say if propagation between clients and non-clients still remains default as per 4456 or does your rules also apply between those groups ? Thx, RR :) On Tue, Jul 9, 2019 at 1:53 PM Dongjie (Jimmy) wrote: > Hi Robert, > > > > Thanks a lot for your prompt comments. Please see some replies inline wit= h > [Jie]. > > > > *From:* Robert Raszuk [mailto:robert@raszuk.net] > *Sent:* Monday, July 08, 2019 8:02 PM > *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) < > gunter.van_de_velde@nokia.com>; Dongjie (Jimmy) ; > Zhuangshunwan > *Cc:* idr@ietf. org > *Subject:* Re: I-D Action: draft-dong-idr-node-target-ext-comm-01.txt > > > > Dear authors, > > > > Let me start by restating that using a p2mp protocol to distribute > information in a p2p fashion is a bad thing. Your proposal just further > encourages folks to do continue use of BGP along those lines which is not= a > good thing. > > > > [Jie] This document just provides a mechanism to solve some operator=E2= =80=99s > requirement in using existing tools. It does not encourage anything:) > > > > Now few questions/observations: > > > > * You are explicitly breaking RFC4456. The node which does your policy > enforcement - let's call it - BGP Policy based Update Replicator (BGP PUR= ) > - no longer follows RFC4456 recommendations of route propagation from > client to non-client and from non-client to client. Sure you may define > such new functional block in BGP but IMHO this is no longer a vanilla Rou= te > Reflector with "just a little bit more filtering" :) > > > > [Jie] You are right this would require some update to vanilla RR > functionality, RFC 4456 may be updated by this document. In the past, RTC > has also made some changes to the RR behavior. > > > > * Assume that in my 500 PEs IPv6 network I want to distribute some > information to 100 of them. Very conservative case. So with the current > draft I will need to send with each route BGP Extended Community Attribut= e > of the 2K size. Well assume that BGP Extended Message is not there at lea= st > on one of the PEs the proposed scheme breaks. Did you ever consider to > actually define new attribute for this and support wildcard match/extende= d > community match length ? > > > > [Jie] The initial problem space is to distribute some information to one > or a small group of the BGP routers in the network. In the case you > described, wildcard matching may be more efficient, while it requires to > configure the 100 nodes with the same prefix for wildcard matching. > > > > * Can you describe the rational for keeping the Node Targets ext > communities still in the update when reflecting it to one of the targets = on > the list ? > > > > [Jie] The Node Target extended communities are used by the receiving node= s > to identify whether it should keep and use the received information or no= t. > With this mechanism, RR only need to check the and remove the node target > extended community which identifies itself, which is easier than checking > the IDs of all its clients. > > > > * Have you thought of using 4 octet BGP identifier instead of peering > address ? First you no longer need to struggle with IPv6 length, you no > longer worry about link-local peerings and you no longer need to touch al= l > senders when interface addresses get renumbered. > > > > [Jie] Good suggestion. This was discussed during the presentation of this > document in last year. We considered two options: using BGP Identifier or > the local (preferably the loopback IP address). As you mentioned, there a= re > some advantages in using BGP Identifier. We could make this change in nex= t > version. > > > > * RRs in general where designed and optimized to reflect all received > updates. RTC came and applied some outbound filters. Now your proposal > comes and applies new set of per peer dynamic filters. Putting > implementation details aside at min your proposal must define which filte= r > is more important RTC pushed from target or your Target RT pushed from > sources. > > > > [Jie] This is part of the reason of defining a new extended community > which is independent from RT. RTC rules applie to the RT in the VPN route= s, > while the rules defined in this document apply to this Node Target Extend= ed > Community. If one Update carries both RT and Node Target, then both rules > would be used separately to determine how to send and receive the Update. > > > > * How does your proposal works with RR hierarchy ? It seems pretty clear > that it only works with flat sender -- RR -- receiver architecture. > > > > [Jie] Good question. In general RR hierarchy could be supported, while > further study is needed to cover the corner cases, this is similar to the > work we have been doing with RTC. > > > > * How does your proposal work with confederations ? > > > > [Jie] If there is requirement to support confederation, It could be > covered in next version. > > > > * What happens when session to a peer goes down ? Would you now need to > remodify the list of Node Target Ext Comms and resend to other IBGP peers > including that node which you have lost IBGP to ? > > > > [Jie] I don=E2=80=99t quite get your question here. The list of Node Targ= et > extended communities is not be modified by a route reflector unless a loc= al > address matches one of the node target. As discussed above, the node targ= et > which identifies a peer node will not be removed by the RR. > > > > Essentially what you are defining is to push dynamic filtering policy fro= m > the src to the RRs hoping that RRs will honor it and apply proper outboun= d > filters. Moreover you are also adding new behaviour for RRs to modify > content of BGP attributes upon reflection. I think you are assuming that > all applicable implementations support dynamic update groups or are you > assuming that whenever such Node Target Ext Community arrive on the RR it > should switch for a given SAFI to per peer update generation ? > > > > [Jie] IMO the changes to the RR=E2=80=99s behavior in this document is sm= aller > than you thought, in current version it is hard to call it =E2=80=9CRR wi= th > outbound filtering=E2=80=9D, although it may be extended further in that = direction. > So far it does not require to support dynamic update groups. > > > > Best regards, > > Jie > > > > Best, > R. > > > > > > > On Mon, Jul 8, 2019 at 1:13 PM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : BGP Extended Community for Identifying the > Target Node > Authors : Jie Dong > Shunwan Zhuang > Gunter Van de Velde > Filename : draft-dong-idr-node-target-ext-comm-01.txt > Pages : 7 > Date : 2019-07-08 > > Abstract: > BGP has been used to distribute different types of routing and policy > information in the network. In some cases, the information > distributed may be only intended for one or several particular > receiving BGP nodes in the network. However, BGP does not have a > general mechanism for designating the receiving node of the routing > information. This document defines a new type of BGP extended > community called "Node Target". The mechanism of using the Node > Target extended community to steer BGP route distribution to > particular BGP nodes is specified. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-dong-idr-node-target-ext-comm/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-dong-idr-node-target-ext-comm-01 > > https://datatracker.ietf.org/doc/html/draft-dong-idr-node-target-ext-comm= -01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-dong-idr-node-target-ext-comm-0= 1 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --000000000000fad973058d42cd11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jie,

I think you are unde= restimating the effort to implement it correctly on the RRs :)=C2=A0
<= div>
Two clarifications to my points below:=C2=A0

> If one Update carries both RT and Node Targe= t, then both rules would be used=C2=A0
> separa= tely to determine how to send and receive the Update.=C2=A0=C2=A0

It is not about if those are used separately or = together ... this is implementation detail.=C2=A0 What however matters in t= he spec is clear articulation if update needs to be sent when RTC is asking= for it yet Node Target does not list a given peer (and vice-versa).=C2=A0<= br>

> [Jie] I don=E2=80=99t quite get y= our question here. The list of Node Target extended communities=C2=A0
> is not be modified by a route reflector unless a l= ocal address matches one of the node=C2=A0
> ta= rget. As discussed above, the node target which identifies a peer node will= not be removed by the RR.=C2=A0=C2=A0

= Yes I am pointing out the "unless" situation.=C2=A0=C2=A0

When interface goes down to the peer you have sent it to = you need to now resend that subset of updates with modified Ext Community A= ttribute to other peers. In general the draft does not even say if propagat= ion between clients and non-clients still remains default as per 4456 or do= es your rules also apply between those groups ?=C2=A0=C2=A0
<= br>
Thx,
RR :)


On Tue, Jul 9, 2019 at 1:5= 3 PM Dongjie (Jimmy) <jie.dong@hu= awei.com> wrote:

Hi Robert,

=C2=A0=

Thanks a lot for your promp= t comments. Please see some replies inline with [Jie].=

=C2=A0=

From: Robert Raszuk [mailto:robert@raszuk.net]
Sent: Monday, July 08, 2019 8:02 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.= com>; Dongjie (Jimmy) <jie.dong@huawei.com>; Zhuangshunwan <zhuangshunwan@huawei.com>
Cc: idr@ietf. org <idr@ietf.org>
Subject: Re: I-D Action: draft-dong-idr-node-target-ext-comm-01.txt<= u>

=C2=A0

Dear authors,

=C2=A0

Let me start by restating that = using a p2mp protocol to distribute information in a p2p fashion is a bad t= hing. Your proposal just further encourages folks to do continue use of BGP= along those lines which is not a good thing.=C2=A0

=C2=A0=

[Jie] This document just pr= ovides a mechanism to solve some operator=E2=80=99s requirement in using ex= isting tools. It does not encourage anything:)

=C2=A0

Now few questions/observations:= =C2=A0

=C2=A0

* You are explicitly breaking R= FC4456. The node which does your policy enforcement - let's call it - B= GP Policy based Update Replicator (BGP PUR) - no longer follows RFC4456 rec= ommendations of route propagation from client to non-client and from non-client to client. Sure you may define such new = functional block in BGP but IMHO this is no longer a vanilla Route Reflecto= r with "just a little bit more filtering" :)=C2=A0<= /span>

=C2=A0=

[Jie] You are right this wo= uld require some update to vanilla RR functionality, RFC 4456 may be update= d by this document. In the past, RTC has also made some changes to the RR behavior.

=C2=A0

* Assume that in my 500 PEs IPv= 6 network I want to distribute some information to 100 of them. Very conser= vative case. So with the current draft I will need to send with each route = BGP Extended Community Attribute of the 2K size. Well assume that BGP Extended Message is not there at least o= n one of the PEs the proposed scheme breaks. Did you ever consider to actua= lly define new attribute for this and support wildcard match/extended commu= nity match length ?=C2=A0

=C2=A0=

[Jie] The initial problem s= pace is to distribute some information to one or a small group of the BGP r= outers in the network. In the case you described, wildcard matching may be more efficient, while it requires to configure th= e 100 nodes with the same prefix for wildcard matching.

=C2=A0

* Can you describe the rational= for keeping the Node Targets ext communities still in the update when refl= ecting it to one of the targets on the list ?=C2=A0

=C2=A0=

[Jie] The Node Target exten= ded communities are used by the receiving nodes to identify whether it shou= ld keep and use the received information or not. With this mechanism, RR only need to check the and remove the node ta= rget extended community which identifies itself, which is easier than check= ing the IDs of all its clients.

=C2=A0

* Have you thought of using 4 o= ctet BGP identifier instead of peering address ? First you no longer need t= o struggle with IPv6 length, you no longer worry about link-local peerings = and you no longer need to touch all senders when interface addresses get renumbered.=C2=A0

=C2=A0=

[Jie] Good suggestion. This= was discussed during the presentation of this document in last year. We co= nsidered two options: using BGP Identifier or the local (preferably the loopback IP address). As you mentioned, there= are some advantages in using BGP Identifier. We could make this change in = next version.

=C2=A0

* RRs in general where designed= and optimized to reflect all received updates. RTC came and applied some o= utbound filters. Now your proposal comes and applies new set of per peer dy= namic filters. Putting implementation details aside at min your proposal must define which filter is more import= ant RTC pushed from target or your Target RT pushed from sources.=C2=A0<= /u>

=C2=A0=

[Jie] This is part of the r= eason of defining a new extended community which is independent from RT. RT= C rules applie to the RT in the VPN routes, while the rules defined in this document apply to this Node Target Extende= d Community. If one Update carries both RT and Node Target, then both rules= would be used separately to determine how to send and receive the Update.<= u>

=C2=A0

* How does your proposal works = with RR hierarchy ? It seems pretty clear that it only works with flat send= er -- RR -- receiver architecture.=C2=A0

=C2=A0=

[Jie] Good question. In gen= eral RR hierarchy could be supported, while further study is needed to cove= r the corner cases, this is similar to the work we have been doing with RTC.

=C2=A0

* How does your proposal work w= ith confederations ?=C2=A0

=C2=A0=

[Jie] If there is requireme= nt to support confederation, It could be covered in next version.

=C2=A0

* What happens when session to = a peer goes down ? Would you now need to remodify the list of Node Target E= xt Comms and resend to other IBGP peers including that node which you have = lost IBGP to ?=C2=A0

=C2=A0=

[Jie] I don=E2=80=99t quite= get your question here. The list of Node Target extended communities is no= t be modified by a route reflector unless a local address matches one of the node target. As discussed above, the node target which = identifies a peer node will not be removed by the RR.

=C2=A0

Essentially what you are defini= ng is to push dynamic filtering policy from the src to the RRs hoping that = RRs will honor it and apply proper outbound filters. Moreover you are also = adding new behaviour for RRs to modify content of BGP attributes upon reflection. I think you are assuming that a= ll applicable implementations support dynamic update groups or are you assu= ming that whenever such Node Target Ext Community arrive on the RR it shoul= d switch for a given SAFI to per peer update generation ?=C2=A0

=C2=A0=

[Jie] IMO the changes to th= e RR=E2=80=99s behavior in this document is smaller than you thought, in cu= rrent version it is hard to call it =E2=80=9CRR with outbound filtering=E2=80=9D, although it may be extended further in that direction.= So far it does not require to support dynamic update groups.=

= =C2=A0

Best regards,=

Jie

=C2=A0=

Best,
R.

=C2=A0

=C2=A0

> On Mon, Jul 8, 2019 at 1:1= 3 PM <inte= rnet-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= BGP Extended Community for Identifying the Target Node
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Jie = Dong
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Shunwan Zhuang
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Gunter Van de Velde
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-don= g-idr-node-target-ext-comm-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-07-08

Abstract:
=C2=A0 =C2=A0BGP has been used to distribute different types of routing and= policy
=C2=A0 =C2=A0information in the network.=C2=A0 In some cases, the informati= on
=C2=A0 =C2=A0distributed may be only intended for one or several particular=
=C2=A0 =C2=A0receiving BGP nodes in the network.=C2=A0 However, BGP does no= t have a
=C2=A0 =C2=A0general mechanism for designating the receiving node of the ro= uting
=C2=A0 =C2=A0information.=C2=A0 This document defines a new type of BGP ext= ended
=C2=A0 =C2=A0community called "Node Target".=C2=A0 The mechanism = of using the Node
=C2=A0 =C2=A0Target extended community to steer BGP route distribution to =C2=A0 =C2=A0particular BGP nodes is specified.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-dong-idr-no= de-target-ext-comm/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-dong-idr-node-targe= t-ext-comm-01
https://datatracker.ietf.org/doc/html/draft= -dong-idr-node-target-ext-comm-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-don= g-idr-node-target-ext-comm-01


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--000000000000fad973058d42cd11--