MIME-Version: 1.0
References: <CC0D8A2E-8992-43FD-8604-E804C9F3780E@tony.li>
 <8876B117-7E24-476A-99AA-A8EFD1140EFB@gmail.com>
 <E4DAA22D-023C-4373-B2D5-B7B19FFE0627@tony.li>
 <CACe62MnKsx+jKNBUgjEuCnEWmvfGz0os87SPSv8bMtFT5xKz5Q@mail.gmail.com>
 <8B1EDA43-DA92-43F6-B6BE-7946424EBF35@tony.li>
 <CAOj+MMHhxeYB3yuO6AMpK7Z_DSm-j8-PtqTAH5RydB_Sq7bjsw@mail.gmail.com>
 <2405D836-75B1-4C1D-865F-317AE0E63BA7@tony.li>
 <CAOj+MMGiNP_wbEh7OEOC7t34fF1xkSvdY581B0TeLWO0a-8K1A@mail.gmail.com>
 <4A63DEA5-F014-469B-A589-499B2C14550D@tony.li>
 <CAOj+MMENRC6GeahZ4+UtczwgHyUAC=kHXXKRED8yCJWSxdVfBQ@mail.gmail.com>
 <0AFB449A-37D6-4A97-8770-206E5DEFFF13@tony.li>
 <CAOj+MMH5WJ7oSkOU=NPLA+gwfX9Am6jz-+y+Qnv8yA2bizMRaw@mail.gmail.com>
 <BY1PR84MB3954836FA0810A56C909B5EA920F2@BY1PR84MB3954.NAMPRD84.PROD.OUTLOOK.COM>
In-Reply-To: 
 <BY1PR84MB3954836FA0810A56C909B5EA920F2@BY1PR84MB3954.NAMPRD84.PROD.OUTLOOK.COM>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 22 May 2026 14:02:51 +0200
Message-ID: 
 <CAOj+MMEcw3rZdwLghEsVWvhAXQh3m7tL9bSdEEkrJnq+Cb+NCg@mail.gmail.com>
To: "Barth, Colby" <jonathan.barth@hpe.com>
Content-Type: multipart/alternative; boundary="00000000000095f6b5065266cf98"
Message-ID-Hash: PWGBUHRVEF53ITUN2PQY3MTZIXSVCE4A
CC: Tony Li <tony.li@tony.li>, Carlos Pignataro <cpignata@gmail.com>,
 Christian Hopps <chopps@chopps.org>, lsr <lsr@ietf.org>,
 "lsr-ads@ietf.org" <lsr-ads@ietf.org>, ops-ads <ops-ads@ietf.org>,
 "green@ietf.org" <green@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BGreen=5D_Re=3A_=5BLsr=5D_Next_steps_for_draft-many-lsr-power-gr?=
	=?utf-8?q?oup-02?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/green/IvVwTMw_bHPkU5vPC-tM9Wspa7Q>

--00000000000095f6b5065266cf98
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Colby,

Ok so *all* headends need to be smart and apply rule of traffic aggregation
> (180 degrees to one of traditional uses of TE which is traffic
> spreading over available topology).
>
> <cb> An operator has the choice to deploy such a solution if power saving=
s
> is important to them.
>

So let's zoom on this for a second ...

How would an operator enable this ? Clearly all headends in the network (at
those which are used for SLA sensitive traffic) need to be upgraded and
enabled.

But how do you enable this ?

Are you saying that now traffic spread by TE across links is no longer
important and power savings becomes prime citizen ?

Or are you saying that this optimization would be enabled between 1:00 AM
and 6:00 AM ? Well for Tier-1 or even some Tier-2 backbones there is never
night everywhere. In fact there always daylight in some part of the world.
So here we are now talking about properly designed networks with
areas/levels corresponding to traffic patterns.

<cb> The draft defines a power-save capability for a link, section 7.3.4.
> Resilient topologies can be designed or calculated (periodically, on
> demand, =E2=80=A6) such that resilience is not compromised.  Links just n=
eed to be
> marked as not-available-for-power-sleep.
>

The point I am highlighting is that FRR protection is fully distributed in
the network and is beyond control of the headend.

PLRs can not guess which links will be shut in the future unless you mark
all as "not-available-for-power-sleep". To come back to Tony's example if
North link is marked as "not-available-for-power-sleep" and we put to sleep
Central and South some PLRs may no longer have a repair path available.

Moreover that knowledge is not readily available on each headend as they
can not predict the future how other headends will behavie in time T+N.

<cb> FRR tunnels can be moved apriori or after-the-fact but either way,
> there would be a resilient topo available for FRR tunnel placement.
>

Very topology dependent assumption and clearly and significantly reducing
the space for savings.

Thx,
Robert

--00000000000095f6b5065266cf98
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Colby,</div><div><br></div><div class=3D"gmail_quo=
te gmail_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div><div id=3D"m_-2475770721608898898mail-editor-reference-message-contai=
ner"><div style=3D"direction:ltr">Ok so *all* headends need to be smart and=
 apply rule of traffic aggregation (180 degrees to one of traditional uses =
of TE which is traffic spreading=C2=A0over available topology).=C2=A0</div>
<div style=3D"direction:ltr">
<br>
</div>
<div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo=
nt-size:12pt;color:rgb(0,0,0)">
&lt;cb&gt; An operator has the choice to deploy such a solution if power sa=
vings is important to them.</div></div></div></blockquote><div><br></div><d=
iv>So let&#39;s zoom on this for a second ...=C2=A0</div><div><br></div><di=
v>How would an operator enable this ? Clearly=C2=A0all headends=C2=A0in the=
 network (at those which are used for SLA sensitive traffic) need to be upg=
raded and enabled.=C2=A0</div><div><br></div><div>But how do you enable thi=
s ?=C2=A0</div><div><br></div><div>Are you saying that now traffic=C2=A0spr=
ead by TE across links is no longer important=C2=A0and power savings become=
s prime citizen ?=C2=A0</div><div><br></div><div>Or are you saying that thi=
s optimization would be enabled between 1:00 AM and 6:00 AM ? Well for Tier=
-1 or even some Tier-2 backbones there is never night everywhere. In fact t=
here always daylight in some part of the world. So here we are now talking =
about properly designed networks with areas/levels corresponding to traffic=
 patterns.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div><div id=3D"m_-2475770721608898898mail-editor-reference-mes=
sage-container"><div style=3D"direction:ltr"><span style=3D"color:rgb(0,0,0=
);font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt">&lt;cb&gt; T=
he draft defines a power-save capability for a link, section 7.3.4.=C2=A0 R=
esilient topologies can be designed or calculated (periodically, on demand,=
 =E2=80=A6) such that resilience is not compromised.=C2=A0 Links just need =
to be marked as not-available-for-power-sleep.</span></div></div></div></bl=
ockquote><div><br></div><div>The point I am highlighting is that FRR protec=
tion is fully distributed in the network and is beyond control of the heade=
nd.=C2=A0</div><div><br></div><div>PLRs can not guess which links will be s=
hut in the future unless you mark all as &quot;not-available-for-power-slee=
p&quot;. To come back to Tony&#39;s example if North link is marked as &quo=
t;not-available-for-power-sleep&quot; and we put to sleep Central and South=
 some PLRs may no longer have a repair path available.=C2=A0</div><div><br>=
</div><div>Moreover that knowledge is not readily available on each headend=
 as they can not predict the future how other=C2=A0headends will behavie in=
 time T+N.=C2=A0=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div><div id=3D"m_-2475770721608898898mail-editor-referen=
ce-message-container"><div style=3D"direction:ltr"><span style=3D"color:rgb=
(0,0,0);font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt">&lt;cb=
&gt; FRR tunnels can be moved apriori or after-the-fact but either way, the=
re would be a resilient topo available for FRR tunnel placement.</span></di=
v></div></div></blockquote><div><br></div><div>Very topology dependent assu=
mption and clearly and significantly reducing the space for savings.=C2=A0<=
/div><div><br></div><div>Thx,</div><div>Robert</div><div><br></div></div></=
div>

--00000000000095f6b5065266cf98--