Return-Path: X-Original-To: bess@mail2.ietf.org Delivered-To: bess@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E7BE41079194C for ; Thu, 25 Jun 2026 15:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782425079; bh=8K1e7ECWRDLteYa9D0ipZrDll1XkPVZsPTSPQnqBNLM=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=A6oH7qmDTscXUpON1bvFoOUsHAd+NrAG6oHd8AW1MHYKvjyVS2E1ZEbmTJ31WF8wp O4FYeM8QUO6V4he1LHkGSu11F/80wZ6HAyUQODCzWoqnDk2iWn/hDXhggJEU1yRapS jbe6nfv8JMFuG9lZMu1v4M1KS4p822CFcVLNJ9zQ= X-Virus-Scanned: amavisd-new at ietf.org 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPjtKKa2w2dB for ; Thu, 25 Jun 2026 15:04:37 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B992F10791933 for ; Thu, 25 Jun 2026 15:04:37 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-69531108f25so515911a12.2 for ; Thu, 25 Jun 2026 15:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782425077; x=1783029877; darn=ietf.org; h=content-language:thread-index:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TNcjWwtiYoW1JAPAnFbAuawN/nd5VKeKu1ZL/d7prIc=; b=LeLXz2vpWev1OhMZTtoBDaeU6ANBzbRdYvCEHP0wfuyJixURUPK0dh0EnIIXaoaGHE wmf/BmReXevBLHO+B+C3Ji7ecXWihAHLHkad1wOutxlMzOkfRViebCQSEKEfbTiMKs9r 8HD5R5WY3TGiIV4D+HNl6qsKUfLyvUxQKszdf5pUzBbgVSRpKYAAuQ6ICyk4LzEMD7Ck lL3JCPXxyIT5ZBb0l+LQbVj27n3Z5VBpV5SsYWJs4OOOgPhR/r0BH7+eMQf+gZSQq0xz IP8ma52BkXKzRtbiqtcS7VleJTp/joRiDKoj/doXErU0tUgADyrucb6SHI4UKKlp2Tt8 +2sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782425077; x=1783029877; h=content-language:thread-index:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=TNcjWwtiYoW1JAPAnFbAuawN/nd5VKeKu1ZL/d7prIc=; b=XSkcKwMg3lBmRFv90J18ADnPewZDP4XITdUaIsBiag2WCrBZ6txdeWEv0Qz8Ppx07T rhNTWb9gQJOQYNNuC72MtjgKqIT1JQ7iuUeyCPfGStKX7aDzsVCBFCnKJv8mNLtqPfB2 k0uL91DRi9wff4V0ekYX9HK+sUzOaYIEl0NNKXV4jIjgRPw08xq/qnybo1hpk3bwHT8+ MKB7stNmn2HZatg2AMscXhDOhO7Uuy5ETJvT5I8esdKAJpyOdO3GW5Bbn+1v517p2Bqy xZxGPG3c+slgqL7qtd4yfsYfLK9hyhuxkzq3hLazuyRZ7JIdJuAmKIDwDPyWHKclMe3X AceQ== X-Gm-Message-State: AOJu0YzuXEdI/0sgGpQeUtpKCmR/aHHhENNjFUW7T5zYVGZfUANq6k7g Px2oVzr7l41p6qKMPxA8LObeadoGlyd6LFHXkychFCupTVOzwIqnCkehoF+8xac= X-Gm-Gg: AfdE7cmNpPRUL6uxK79JndW1cLp+fy3Z+pO1eYDJWmzJnWNylx/P25kxiAeSO3jedVJ LCtF9D2/2JOgm8yPbbzdg4BqrGmg89CogqhapnZNJqCwuKKSUiw7V2N4lJXdEO1cNYerb8KWhrp gS9DSJmGHCnRAc/wqLsaRTQIGqIXIYdVmTvuhgZMxkQ+I7mdCaL1OW7moU8RhS2fxpDS+DMAXmg de0S/Qz8fd5P6SzvmUuDU4GXNqI9zJgElqeyToP9jm+yICXjw9CD2DQ4reD67taH1Fa2XbD2Mox Db0Gncr7vmOAJ2m4zBJcB74hhWfexodgeaNv6oCMULy8iSwBGZPmsqGsgCkNkeCtqvI+wd2EXK0 rjG1+z3kWIfT00lv/MzuUZWD0HTzz9pJWzhHO8HbqcuRK7qOxK2HbF0KrQ0/2yuJDnvVzgia0AR m1zlJvHEUWBrE+LNB7bI+Anksh6E4Em4I= X-Received: by 2002:a17:907:86a4:b0:c03:cad0:f003 with SMTP id a640c23a62f3a-c1205d787a0mr271663366b.14.1782425076242; Thu, 25 Jun 2026 15:04:36 -0700 (PDT) Received: from CSCOWPF4BBQ4D ([173.38.220.52]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c11fbffcb40sm250720866b.63.2026.06.25.15.04.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2026 15:04:35 -0700 (PDT) From: To: "'Tiger Xu'" , "'Jeffrey Haas'" , "'Gunter Van de Velde'" , References: <20260527125612.GA17917@pfrc.org> In-Reply-To: Date: Fri, 26 Jun 2026 00:04:33 +0200 Message-ID: <09fc01dd04ee$9af2bdb0$d0d83910$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09FD_01DD04FF.5E7D3B60" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJJWG9Fk8gzwbtC4DpuGlRG1GUBjwHnB2YMAb5C2jkB/HOkmbVKF1sg Content-Language: fr Message-ID-Hash: YNI7A2PA2FCDMYLFNF27TVJM5P3UXIZN X-Message-ID-Hash: YNI7A2PA2FCDMYLFNF27TVJM5P3UXIZN X-MailFrom: slitkows.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: 'BESS' , "'idr@ietf. org'" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bbess=5D_Re=3A_=5BIdr=5D_Working_Group_Last_Call_on_draft-ietf-b?= =?utf-8?q?ess-ebgp-dmz?= List-Id: BGP-Enabled ServiceS working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_09FD_01DD04FF.5E7D3B60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi folks, > For this point, I'll ask that the DMZ authors respond to the = provenance of the use case. =20 =20 As it was pointed on the mic during multiple IETF meetings [1] [2], the = =E2=80=9Cmin BW=E2=80=9D use case is already implemented using the link = bandwidth community with no requirement of introducing a new community. =20 There are documentations available showing the behavior ([3]). In [3], = we have: =E2=80=9CRouter D (198.51.100.0)=E2=80=99s link-capacity of 20Gb is less = than the aggregate link capacity of 30Gb so Router C only advertises = 20Gb to Router D. =E2=80=A6 Unlike Router D, Router E receives the total link bandwidth of 30Gb. = This is because Router E=E2=80=99s peering link capacity is 40Gb, so the = advertised link-bandwidth of 30Gb is not subject to capping.=E2=80=9D =20 =20 On the other hand, Cisco IOS XR also supports mathematical functions = based on local link BW and learned remote BW. This is a superset of the = capabilities (=E2=80=9Cmin=E2=80=9D) defined in the other draft and = these capabilities were driven by customer requests. =20 route-policy SET_LBW set effective-bandwidth install value function ( received-bandwidth * = link-bandwidth ) set effective-bandwidth install value / 1250000 end-policy ! =20 =20 As the ebgp-dmz draft is the WG document carrying the existing = deployments of the BGP LBW community, it had to be updated with all what = the existing implementation support. As the initial editor of the draft = moved to another company, it took some time to update the document = (version 4 was the last update from original editor =3D> December 2023). = Again, updates are just reflecting existing deployments of the link = bandwidth community as stated multiple times and presented during IETF = meetings. =20 =20 [1] Minutes from IETF 123 =E2=80=9C7. Fully Adaptive Routing Ethernet using BGP 10:38 (10 mins) draft-xu-idr-fare-03 = [Xiaohu Xu] * Stephane Litkowski: we should not introduce a new BGP extended community to do this; some assumptions on other work may have been true but aren't anymore, we have all the tools now with the existing attributes. There are implementations based on existing attributes. Concern what will happen if we have multiple ways to encode the same thing. We have a community container for bandwidth, What's encoded is really up to local behavior, cf. accumulation in the bess-DMZ draft. It is fine to define it as a new use case, but not a new standard. * Tobias Fiebig: +1 to previous comment, also very IPv4 centric, really need to consider IPv6.=E2=80=9D =20 [2] Minutes/recording from IETF125 at around 39:45=20 =20 [3] = https://mirror.wide-net.org/pub/b/BGP_UCMP.pdf =20 =20 =20 Hope it clarifies, =20 Brgds, =20 Stephane =20 =20 =20 From: Tiger Xu =20 Sent: Saturday, June 13, 2026 6:22 AM To: Jeffrey Haas ; Gunter Van de Velde = ; bess-chairs@ietf.org Cc: BESS ; idr@ietf. org Subject: =E7=AD=94=E5=A4=8D: [Idr] Working Group Last Call on = draft-ietf-bess-ebgp-dmz =20 Hi Jeff, =20 I apologize for missing your email. Please see my response inline with = [Tiger]. =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Jeffrey Haas > =E6=97=A5=E6=9C=9F: =E6=98=9F=E6=9C=9F=E4=B8=89, = 2026=E5=B9=B45=E6=9C=8827=E6=97=A5 20:56 =E6=94=B6=E4=BB=B6=E4=BA=BA: Tiger Xu >, Gunter Van de Velde = >, = bess-chairs@ietf.org = > =E6=8A=84=E9=80=81: BESS >, = idr@ietf. org > =E4=B8=BB=E9=A2=98: Re: [Idr] Working Group Last Call on = draft-ietf-bess-ebgp-dmz Tiger, Some of these questions are impacting progression of the DMZ draft. = Would you please respond: On Wed, May 06, 2026 at 10:02:01AM -0400, Jeffrey Haas wrote: > [Speaking as an IDR chair and the shepherd for the DMZ document in = this response] >=20 > > Fourth, the new use cases and associated technical approaches = introduced in draft-ietf-bess-ebgp-dmz -07 (published 20 July 2025) were = already fully and explicitly documented in draft-xu-idr-fare -00 = (released 1 July 2024). >=20 > There are certainly overlaps in the problem space between the DMZ and = FARE documents. draft-xu-idr-fare-00 was issued on January 2025. The = DMZ draft had been getting work done on it over several years with = refining use cases. Is there a specific use case you are referring to = here? If so, please clarify what section in the document you're = discussing. [TIger] *draft-xu-idr-fare-00* ( = = https://datatracker.ietf.org/doc/html/draft-xu-idr-fare-00), published = in July 2024, introduces the concept of path bandwidth usage. In = contrast, *draft-ietf-bess-ebgp-dmz-08*, published in October 2025, = introduces path bandwidth usage for the first time as well, specifically = in Section 1 and Section 4.2. See the following quoted text from DMZ-08: =20 =E2=80=9C...The example above shows that the BGP link bandwidth extended = community may not be limited to carry only a "link" bandwidth value. In = our example, the value 30Gbps advertised by R3 represents an aggregated = path bandwidth.=E2=80=9D =E2=80=94quoted from section 1 of DMZ-08 =20 =E2=80=9C...BGP may have to consider a combination of the local link and = remote bandwidth when computing the weights for weighted load-balancing. = Any function of the two may be used like for instance a "minimum" = function that was highlighted in = = Section 1. =E2=80=9C =E2=80=94quoted from section 4.2 of DMZ-08 =20 For more details, see = = https://author-tools.ietf.org/iddiff?url1=3Ddraft-ietf-bess-ebgp-dmz-07&u= rl2=3Ddraft-ietf-bess-ebgp-dmz-08&difftype=3D--hwdiff) > Also, is there a concern that there is work covered in that = overlapping portion of the documents that have undisclosed IPR = considerations? Or, is this more a matter that the DMZ document = appropriated a use case without attribution to its contributors? The above impacts both attribution and IPR. =20 [Tiger] Both. I will ask my legal colleague to submit the IPR disclose.=20 > > Further detailed analysis is presented below. IMHO, the IETF, as a = leading global standards-setting body, ought not to endorse or tolerate = such non-compliant community practices. Allowing such precedent would = undermine the IETF=E2=80=99s reputation for impartiality and erode its = ecosystem of original technical innovation. >=20 > I'll address the technical points below, but what "non-compliant = community practices" are you referring to? Please be explicit. Would you clarify what non-compliant practices you're discussing? =20 [Tiger] Non-compliant community practices involve copying ideas from = other drafts and then competing with those drafts. If the IETF tolerates = such practices, it would force more authors to resort to IPR to defend = their intellectual efforts. That would be a dilemma for the IETF = community. > > 2. Issues and solutions introduced in version -08 > > Version -08 adds: > > =E2=80=9CIn addition, as illustrated in the previous sections, BGP = may have to consider a combination of the local link and remote = bandwidth when computing the weights for weighted = load=E2=80=91balancing. Any function of the two may be used like for = instance a =E2=80=98minimum=E2=80=99 function =E2=80=A6 The weight of = each path may then be based on either: only the remote bandwidth, only = the local link bandwidth, or a function of both.=E2=80=9D > > This introduces the minimum function (choosing the smaller value = between the link bandwidth and the path bandwidth of the received = route). The draft also acknowledges for the first time the necessity of = path bandwidth: > > =E2=80=9CIn our example, the value 30Gbps advertised by R3 = represents an aggregated path bandwidth.=E2=80=9D > > Again, both the minimum function and the concept of path bandwidth = were already described in draft-xu-idr-fare version -00. >=20 > For this point, I'll ask that the DMZ authors respond to the = provenance of the use case. I'd also suggest to the BESS chairs and AD = to halt progression of the document until that point is settled. = Minimally, if there's an issue of attribution, that should be addressed. [Tiger] Fully agree. Best regards, Tiger > Further, I ask again on this point where there is undisclosed IPR that = you consider an issue for this use case? Would you clarify if there's undisclosed IPR considerations? -- Jeff ------=_NextPart_000_09FD_01DD04FF.5E7D3B60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi folks,

> For this point, = I'll ask that the DMZ authors respond to the provenance of the use = case. 

 

As it was pointed on = the mic during multiple IETF meetings [1] [2], the =E2=80=9Cmin = BW=E2=80=9D use case is already implemented using the link bandwidth = community with no requirement of introducing a new = community.

 

There are = documentations available showing the behavior ([3]). In [3], we = have:

=E2=80=9CRouter D (198.51.100.0)=E2=80=99s = link-capacity of 20Gb is less than the aggregate link capacity of 30Gb = so Router C only advertises 20Gb to Router D.

=E2=80=A6

Unlike Router D, = Router E receives the total link bandwidth of 30Gb. This is because = Router E=E2=80=99s peering link capacity is 40Gb, so the advertised = link-bandwidth of 30Gb is not subject to = capping.=E2=80=9D

 

 

On the other hand, = Cisco IOS XR also supports mathematical functions based on local link BW = and learned remote BW. This is a superset of the capabilities = (=E2=80=9Cmin=E2=80=9D) defined in the other draft and these = capabilities were driven by customer requests.

 

route-policy = SET_LBW

  set effective-bandwidth install value = function ( received-bandwidth * link-bandwidth )

  set = effective-bandwidth install value / 1250000

end-policy

!

 

 

As the ebgp-dmz draft = is the WG document carrying the existing deployments of the BGP LBW = community, it had to be updated with all what the existing = implementation support. As the initial editor of the draft moved to = another company, it took some time to update the document (version 4 was = the last update from original editor =3D> December 2023). Again, = updates are just reflecting existing deployments of the link bandwidth = community as stated multiple times and presented during IETF = meetings.

 

 

[1] Minutes from IETF = 123

=E2=80=9C7. Fully Adaptive Routing Ethernet = using BGP

10:38 (10 mins) draft-xu-= idr-fare-03 [Xiaohu Xu]

  • Stephane Litkowski: we should not introduce a = new BGP extended
    community to do this; some assumptions on other work = may have been
    true but aren't anymore, we have all the tools now with = the existing
    attributes. There are implementations based on = existing attributes.
    Concern what will happen if we have multiple = ways to encode the same
    thing. We have a community container for = bandwidth, What's encoded
    is really up to local behavior, cf. = accumulation in the bess-DMZ
    draft. It is fine to define it as a new = use case, but not a new
    standard.
  • Tobias Fiebig: +1 to previous comment, also = very IPv4 centric,
    really need to consider = IPv6.=E2=80=9D

 

[2] Minutes/recording = from IETF125 at around 39:45

 

[3] = https://mirror.wide-net.org/pub/b/BGP_UCMP.pdf

 

 

 

Hope it = clarifies,

 

Brgds,

 

Stephane

 

 

 

From:<= /b> = Tiger Xu <xuxiaohu_ietf@hotmail.com>
Sent: Saturday, = June 13, 2026 6:22 AM
To: Jeffrey Haas <jhaas@pfrc.org>; = Gunter Van de Velde <gunter.van_de_velde@nokia.com>; = bess-chairs@ietf.org
Cc: BESS <bess@ietf.org>; idr@ietf. = org <idr@ietf.org>
Subject: =E7=AD=94=E5=A4=8D: [Idr] = Working Group Last Call on = draft-ietf-bess-ebgp-dmz

 

Hi = Jeff,

 

I apologize = for missing your email. Please see my response inline with = [Tiger].

 

=E5=8F=91=E4=BB=B6=E4=BA=BA<= b>: = Jeffrey Haas <jhaas@pfrc.org>
=E6=97=A5=E6=9C=9F: = =E6=98=9F=E6=9C=9F=E4=B8=89, 2026=E5=B9=B45=E6=9C=8827=E6=97=A5 = 20:56
=E6=94=B6=E4=BB=B6=E4=BA=BA: Tiger Xu = <xuxiaohu_ietf@hotmail.com&g= t;, Gunter Van de Velde <gunter.van_de_velde@nokia.c= om>, bess-chairs@ietf.org <bess-chairs@ietf.org>
=E6=8A=84=E9=80=81: BESS = <bess@ietf.org>, idr@ietf. = org <idr@ietf.org>
=E4=B8=BB=E9=A2=98: Re: [Idr] = Working Group Last Call on = draft-ietf-bess-ebgp-dmz

Tiger,

Some of = these questions are impacting progression of the DMZ draft.  = Would
you please respond:

On Wed, May 06, 2026 at 10:02:01AM = -0400, Jeffrey Haas wrote:
> [Speaking as an IDR chair and the = shepherd for the DMZ document in this response]
>
> > = Fourth, the new use cases and associated technical approaches introduced = in draft-ietf-bess-ebgp-dmz -07 (published 20 July 2025) were already = fully and explicitly documented in draft-xu-idr-fare -00 (released 1 = July 2024).
>
> There are certainly overlaps in the problem = space between the DMZ and FARE documents. draft-xu-idr-fare-00 was = issued on January 2025.  The DMZ draft had been getting work done = on it over several years with refining use cases.  Is there a = specific use case you are referring to here?  If so, please clarify = what section in the document you're discussing.

[TIger] *= draft-xu-idr-fare-00* (https://datatracker.ietf.org/doc/= html/draft-xu-idr-fare-00), published = in July 2024, introduces the concept of path bandwidth usage. In = contrast, *draft-ietf-bess-ebgp-dmz-08*, published in October 2025, = introduces path bandwidth usage for the first time as well, specifically = in Section 1 and Section 4.2. See the following quoted text from = DMZ-08:

 

=E2=80=9C...Th= e example above shows that the BGP link bandwidth extended community may = not be limited to carry only a "link" bandwidth value. In our = example, the value 30Gbps advertised by R3 represents an aggregated path = bandwidth.=E2=80=9D  =E2=80=94quoted from section 1 of = DMZ-08

 

=E2=80=9C...BG= P may have to consider a combination of the local link and remote = bandwidth when computing the weights for weighted load-balancing. Any = function of the two may be used like for instance a "minimum" = function that was highlighted in Section = 1. =E2=80=9C= =E2=80=94quoted from section 4.2 of DMZ-08

 

[Tiger] = Non-compliant community practices involve copying ideas from other = drafts and then competing with those drafts. If the IETF tolerates such = practices, it would force more authors to resort to IPR to defend their = intellectual efforts. That would be a dilemma for the IETF = community.

> > = 2. Issues and solutions introduced in version -08
> > Version = -08 adds:
> > =E2=80=9CIn addition, as illustrated in the = previous sections, BGP may have to consider a combination of the local = link and remote bandwidth when computing the weights for weighted = load=E2=80=91balancing. Any function of the two may be used like for = instance a =E2=80=98minimum=E2=80=99 function =E2=80=A6 The weight of = each path may then be based on either: only the remote bandwidth, only = the local link bandwidth, or a function of both.=E2=80=9D
> > = This introduces the minimum function (choosing the smaller value between = the link bandwidth and the path bandwidth of the received route). The = draft also acknowledges for the first time the necessity of path = bandwidth:
> > =E2=80=9CIn our example, the value 30Gbps = advertised by R3 represents an aggregated path = bandwidth.=E2=80=9D
> > Again, both the minimum function and = the concept of path bandwidth were already described in = draft-xu-idr-fare version -00.
>
> For this point, I'll ask = that the DMZ authors respond to the provenance of the use case.  = I'd also suggest to the BESS chairs and AD to halt progression of the = document until that point is settled.  Minimally, if there's an = issue of attribution, that should be addressed.

[Tiger]  = Fully agree.

------=_NextPart_000_09FD_01DD04FF.5E7D3B60--