Hi Shraddha,
Happy New Year.
My responses are inline below with [HC2].
Best Regards,
Huaimo
________________________________
From: Shraddha Hegde <[email protected]>
Sent: Wednesday, December 21, 2022 1:55 PM
To: Huaimo Chen <[email protected]>; [email protected]
<[email protected]>; SPRING WG <[email protected]>
Subject: RE: draft-ietf-spring-segment-protection-sr-te-paths
Hi Huaimo,
Pls see inline [SH2]
Juniper Business Use Only
From: Huaimo Chen <[email protected]>
Sent: Monday, December 19, 2022 4:32 AM
To: Shraddha Hegde <[email protected]>; [email protected]; SPRING WG
<[email protected]>
Subject: RE: draft-ietf-spring-segment-protection-sr-te-paths
[External Email. Be cautious of content]
Hi Shraddha,
My comments are inline below with [HC].
Best Regards,
Huaimo
From: spring <[email protected]<mailto:[email protected]>> On
Behalf Of Shraddha Hegde
Sent: Tuesday, November 29, 2022 12:21 AM
To: [email protected]<mailto:[email protected]>; SPRING WG
<[email protected]<mailto:[email protected]>>
Subject: Re: [spring] draft-ietf-spring-segment-protection-sr-te-paths
Bruno,
Thanks for the review and comments.
Pls see inline..
Juniper Business Use Only
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Sent: Friday, November 18, 2022 7:42 PM
To: SPRING WG <[email protected]<mailto:[email protected]>>; Shraddha Hegde
<[email protected]<mailto:[email protected]>>
Subject: draft-ietf-spring-segment-protection-sr-te-paths
[External Email. Be cautious of content]
[speaking as individual contributor]
Hi Shraddha, all,
Please find below comments on section 5 (IGP hold timer for protecting traffic
to failed node)
Following my previous comments on -02, thank you for the updated text in -03.
The current solution is based on a modification of the SPF computation (or FIB
installation not being in sync with the regular SPF). As such, it relies on all
compliant routers to have strictly the same behavior. Otherwise this would
translate into micro-loops for the duration of the hold timer (easily in the
range of 10s or higher IMHO).
1. In order to achieve this consistent behavior on all nodes, I would
welcome a more normative description of the behavior with 2119 key words.
Also since the current algo relies on the spf-back off delay in order for all
nodes the compute their “hold time” SPF on the same LSDB (same set of events) I
think that calls for the use of a standardize back-off delay hence a normative
reference to RFC 8405.
<SH> Yes. I’ll add it.
1.
“A small configurable
delay called spf-delay can be enabled, which will schedule the SPF
after the spf-delay time on receiving the first event. In case of a
node going down, the spf-delay time coupled with fast-flooding can
help to accumulate link-down events reported by all neighbors in one
single SPF. This mechanism is on best effort basis and does not
guarantee that all link-down events are accumulated before SPF is
triggered. If there are flooding delays, the SPF might get triggered
before receiving all events related to node going down.”
A few comments:
- Indeed, the above relies/requires fast flooding. I would suggest adding an
informative reference to an extension improving the current flooding speed
(draft-ietf-lsr-isis-fast-flooding)
<SH> sure. I’ll add
- I don’t think that the proposed trick is good enough nor really works.
Typically spf-delay are configured with a short initial timer to quickly react
to link failure which are the most common. This would not allow to accumulate
multiple events hence different nodes could use a different event/LSP before
your proposed FIB hold-down and this would translate to loops for the duration
of the “hold down”.
- Even if the above would work, I agree that this would be only “best effort”.
I don’t think that this is good enough given the modest gain in good cases
(improved availability on the few SR-TE path using the node going down) and the
cost in bad cases (micro-loops for a relative long duration (e.g. 10s) which
can overload multiple links and reducing availability of all traffic, included
the one prioritized by QoS)
1. Given the two above points, I would rather propose to use a different
solution: instead of using a hold-timer, push a new node SID toward a neighbor
of the failed node, typically the closest one (à la near side tunneling).
Cf draft-hegde-rtgwg-microloop-avoidance-using-spring which you wrote and which
says in the abstract “Micro-looping is generally more harmful than simply
dropping traffic on failed links, because it can cause control traffic to be
dropped on an otherwise healthy link involved in micro-loop. This can lead to
cascading adjacency failures or network meltdown.”
I think that this text is also relevant in the context of
draft-ietf-spring-segment-protection-sr-te-paths.
<SH> Nearside tunnelling indeed looks a better solution as the path to the
nearside node is expected to be on the same path that was used before failure
also the path to nearside node is not subjected to micro-loop.
I’ll update the draft. Would be good to keep just one procedure instead of
multiple so I would prefer removing the hold down procedure.
Note that instead of using the closest neighbor, one could also use the
neighbor advertising the mirror SID for the failed node (as defined in RFC 8667
and 8402). The use of tunneling/pushing a SID allows for this choice to be
local and hence implementation dependent.
<SH> What you are proposing here is same as the mechanisms described in
draft-hu-spring-segment-routing-proxy-forwarding. I have below concerns with
this approach.
1. The node advertising mirror SID may not be in the same path towards
destination and is subjected to micro-loops
[HC]: Can you give a case with more details, wherein the hold down solution
does not have micro-loop, but the other solution has?
[SH2] what I am trying to say here is that near-side tunnelling will not have
micro-loop but if other neighbors are used for tunnelling (based on mirror sid)
there may be micro-loops on the path.
[HC2]: Did you imply that the mechanisms described in
draft-hu-spring-segment-routing-proxy-forwarding have micro-loops? If so, can
you show that our solution has more micro-loops than your solution?
1. The protection path varies to a large extent compared to original TE Path
which may not be desirable.
[HC]: A possible failed node (say node F) to be protected here is a loose hop
in the SR-TE path. It seems that no original path (segment) from a upstream
node X to the loose hop F is given by the SR-TE path.
[SH2] Not sure I understand your comment.
[HC2]: The protection we are talking about is mainly about protecting a node
(say node F) with a node SID on a MPLS SR TE path. The node (F) is a loose hop
of the MPLS SR TE path. Suppose that node X is a node on the same MPLS SR TE
path and the upstream (or say previous hop) node of node F. The path segment
from X to F along the MPLS SR TE path is loose. What is the original path
segment from X to F?
1. Traffic may be subjected to double/triple bandwidth booking in some
topologies and some scenarios. This was extensively discussed in mail threads
sometime ago.
[HC]: The node (say node F) to be protected here is a loose hop on the SR-TE
path. Will a upstream node taking a different path (segment) to the loose hop
(node F) cause double/triple bandwidth booking?
[SH2] I am curious If you have real topologies in mind that would cause
bandwidth double booking for the nearside tunnelling solution.
1. When all nodes in the network are upgraded to provide node-protection
there would be maximum benefit and when all nodes are not upgraded, the
nearside tunneling solution provides
Best possible solution, I don’t really see the need for overengineering the
solution for partial upgrade cases.
[HC]: In practice, it takes a long time for a feature to be deployed in a whole
network normally. Can you give more details about why the tunneling solution is
best solution and not overengineering?
[SH2] All protection mechanisms like LFA/TI-LFA/R-LFA provide protection when
upgraded, and we have seen networks deploying them partially and getting
benefits when upgraded.
draft-ietf-spring-segment-protection-sr-te-paths approaches the
problem in same way.
Pls refer my response to Bruno on why nearside tunneling is good enough
solution and my thoughts on solving partial upgrade problem.
[HC2]: The nearside tunneling will not work if the nearside node is not
capable to provide protection for Binding SIDs on the failed node and the MPLS
SR TE path contains a Binding SID of the failed node.
Thank you,
Best regards,
--Bruno
> Bruno,
>
> Snipped...
>
> 1. draft-ietf-spring-node-protection-for-sr-te-paths
>
> "If the Node-SID or Prefix-SID becomes
> unreachable, the event and resulting forwarding changes should not
> communicated to the forwarding planes on all configured routers
> (including PLRs for the failed node) until the hold-timer expires."
>
>
> * It's not crystal clear to me how it would work in reality, so I would
> welcome more prescriptive text. In particular:
> * "node failure" is not an IGP message. IGP nodes sees multiple
"adjacency loss" messages which are not atomic and could be handled in multiple
SPFs. Hence different nodes will freeze their FIB based on a different topology
(link1 for some, link2 for others) leading to inconsistent routing and
forwarding loops.
> <SH> I will add text to capture this point and also add detailed text on
> possible solutions.
>
>
> * How is the FIB modified in cases of consecutives IGP events?
(freezed on hold topology may lead to drops, updating entries would need to be
specified.
> <SH> Agreed.
>
> * On a side node, this text requires a global behavior of all IGP nodes.
> That seem a bit out of scope of a non-normative sentence, in an informational
> document, describing a local behavior on the PLR.
> <SH> I don't think we need any protocol extension for solutions described in
> this document but if WG thinks it should be a standard rather than
> informational
> we should upgrade this document status IMO.
>
> Rgds
> Shraddha
>
>
>
> Juniper Business Use Only
> From: spring [email protected]<mailto:[email protected]> On
> Behalf Of [email protected]<mailto:[email protected]>
> Sent: Wednesday, February 2, 2022 6:56 PM
> To: [email protected]<mailto:[email protected]>; 'SPRING WG'
> [email protected]<mailto:[email protected]>; Huzhibo
> [email protected]<mailto:[email protected]>
> Subject: Re: [spring] WG adoption call -
> draft-hu-spring-segment-routing-proxy-forwarding
>
> [External Email. Be cautious of content]
>
> Hi authors of both documents, WG,
>
> [Speaking as individual contributor.]
>
> It's good to see technical discussions on the restoration of failed SIDs used
> by SR policy.
>
>
> 1. From a functional point of view, can we summarize the benefit to signal
> the node proxy capability?
> e.g.
> - drop the traffic earlier if the PLR does not support proxy capability.
> (helps with congestion)
> - use another proxy off the shortest path (increase congestion but reduce
> loss)
> - possibly help identifying the proxy (nominal is not in the reachable
> topology anymore)
> ...
> Or agree on the absence of significant benefits?
>
>
> 1. draft-ietf-spring-node-protection-for-sr-te-paths
>
> "If the Node-SID or Prefix-SID becomes
> unreachable, the event and resulting forwarding changes should not
> communicated to the forwarding planes on all configured routers
> (including PLRs for the failed node) until the hold-timer expires."
>
>
> * It's not crystal clear to me how it would work in reality, so I would
> welcome more prescriptive text. In particular:
>
> * "node failure" is not an IGP message. IGP nodes sees multiple
"adjacency loss" messages which are not atomic and could be handled in multiple
SPFs. Hence different nodes will freeze their FIB based on a different topology
(link1 for some, link2 for others) leading to inconsistent routing and
forwarding loops.
> * How is the FIB modified in cases of consecutives IGP events?
(freezed on hold topology may lead to drops, updating entries would need to be
specified.
>
> * On a side node, this text requires a global behavior of all IGP nodes.
> That seem a bit out of scope of a non-normative sentence, in an informational
> document, describing a local behavior on the PLR.
>
>
>
>
> 1. draft-hu-spring-segment-routing-proxy-forwarding
> Rather than defining a new "Proxy Forwarding" capability in IGP why don't you
> use the existing Mirroring Segment (from RFC
> https://datatracker.ietf.org/doc/html/rfc8402#section-5.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8402*section-5.1__;Iw!!NEt6yMaO-gk!TiIGZ1oWfUzj6AIX35pvSwyD9BhU_1E0xwkRheX14PjuGLhIolaoExk2oKxHlihC$<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8402*section-5.1*3Chttps*3A*2F*urldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8402*section-5.1__*3BIw!!NEt6yMaO-gk!TiIGZ1oWfUzj6AIX35pvSwyD9BhU_1E0xwkRheX14PjuGLhIolaoExk2oKxHlihC*24__*3BIyUvKg!!NEt6yMaO-gk!Gp81jDYZ3hp9oK7AEli0aYgzF_rpD4qh844i3QpRQpiXqFnQ8gFASrQYxdoEmenRE1xqVEzcPGN9TrPR0BwQxqZ_VQ*24%26data%3D05*7C01*7Chuaimo.chen*40futurewei.com*7C046e5196a53a4d62b00308dad1c99b90*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C638052961106546290*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*7C*7C*7C%26sdata%3DVN*2B2Cq1bCieN3W7Oms*2Bz9alofbrjvYi3fFv4mGz5EbI*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqJSUqJSUlJSUlJSolJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!BV0Sh1dxfCHmVusFS32-Ww2sL1zKgGXb0Pucpe7tX-cWW7LAhCXT1cXG3X0fjVmmL-TS-TwuNwpHTsf2eDovqucC%24&data=05%7C01%7Chuaimo.chen%40futurewei.com%7C8ceda826b91249143bdc08dae384e59f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638072457210635496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k8qu6ip4mhSPKqJMEGLUW%2FrISMaQVxRSUWR%2FXWDzNzs%3D&reserved=0>>)
> whose signaling is already standardized?
> https://datatracker.ietf.org/doc/html/rfc8667#section-2.4.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8667*section-2.4.1__;Iw!!NEt6yMaO-gk!TiIGZ1oWfUzj6AIX35pvSwyD9BhU_1E0xwkRheX14PjuGLhIolaoExk2oLCHtOYr$<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8667*section-2.4.1*3Chttps*3A*2F*urldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8667*section-2.4.1__*3BIw!!NEt6yMaO-gk!TiIGZ1oWfUzj6AIX35pvSwyD9BhU_1E0xwkRheX14PjuGLhIolaoExk2oLCHtOYr*24__*3BIyUvKg!!NEt6yMaO-gk!Gp81jDYZ3hp9oK7AEli0aYgzF_rpD4qh844i3QpRQpiXqFnQ8gFASrQYxdoEmenRE1xqVEzcPGN9TrPR0ByaVdWa4w*24%26data%3D05*7C01*7Chuaimo.chen*40futurewei.com*7C046e5196a53a4d62b00308dad1c99b90*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C638052961106546290*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*7C*7C*7C%26sdata%3DlnWcFDKLhaprTfHz6IUrSzTzd8WqMJLIxLLjf658*2FDw*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqJSUqJSUlJSUlJSolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!BV0Sh1dxfCHmVusFS32-Ww2sL1zKgGXb0Pucpe7tX-cWW7LAhCXT1cXG3X0fjVmmL-TS-TwuNwpHTsf2eH9sVoRa%24&data=05%7C01%7Chuaimo.chen%40futurewei.com%7C8ceda826b91249143bdc08dae384e59f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638072457210635496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9NzB75ALQOrsOQI6PwFZ9tkqWMIs8KXTJsFUOOzSnWQ%3D&reserved=0>>
>
>
> 1. What about the following solution:
>
> * Use mirror SID
> * Tunnel to the "proxy-forwarding" advertising mirror SID
>
> I would see the following benefits:
>
> * No new protocol extensions (cf "3)"
> * Consistent routing in case of multiple SPFs (cf "2)")
> * Benefit from the signaling of the proxy (cf "1)")
>
> Thanks,
> Regards,
> --Bruno
>
>
>
> Orange Restricted
> From:
> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>
>
> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>
> Sent: Tuesday, January 25, 2022 6:13 PM
> To: DECRAENE Bruno INNOV/NET
> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>;
> 'SPRING WG'
> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>
> Subject: RE: [spring] WG adoption call -
> draft-hu-spring-segment-routing-proxy-forwarding
>
> Hi,
>
> I'm NOT supporting this draft for the following reasons:
>
>
> 1. The WG already have a WG document which is dealing with this problem, I
> don't think that WG should come with multiple documents/solutions for the
> same solution space as it may just confuse the industry and create deployment
> issues as different vendors may pick different solutions.
>
>
>
> 1. Adding protocols extensions adds complexity in the solution without
> adding a strong value.
>
>
>
> The document claims that "[I-D.ietf-spring-segment-protection-sr-te-paths]
> ... may not work for some cases such as some of nodes in the network not
> supporting this solution.". While this is true, the proposed solution in
> draft-hu-spring-segment-routing-proxy-forwarding has exactly the same caveat
> and requires all nodes in the network to support the solution.
>
>
>
> Considering the following straight line network: A -B -C -D - E - F - G -H
> and an SR policy from A to H using SID_G, routers A to F have to support the
> extension to make the solution working, if one of the router doesn't support
> the extension, traffic will be dropped.
>
>
>
> Then, there is no value compared to the timer-based solution of
> [I-D.ietf-spring-segment-protection-sr-te-paths]
>
>
>
> Authors of draft-hu-spring-segment-routing-proxy-forwarding argued that G may
> have multiple upstream neighbors let's say F and F' and the solution allows
> for F' to support the extension while F may not support, so the solution will
> send the traffic to F'. Well yes, but this still requires all routers
> upstream to F' to support this extension and maybe F is on the path to F'.
> So, I don't think the argument is valid as it may possibly work tactically
> depending on the network topology when we look at a small portion of the
> network, but when we look at the whole network, operator will have to upgrade
> all their nodes to support the extension to ensure the benefit is there.
>
>
>
> In addition, in term of traffic, forwarding traffic to a neighbor of the
> failed node which wasn't initially on the path, could lead to traffic
> congestion or high traffic peaks on links that were not sized to carry this
> traffic. We could easily expect some traffic tromboning, where traffic goes
> to this non-natural neighbor of the failed node and then goes back over some
> part of the same path before reaching the destination.
>
>
>
> So these protocol extensions are bringing complexity for no value here.
>
>
>
>
> 1. Regarding BSID, I'm not fan of advertising BSIDs in IGP as there may be
> hundreds or thousands of BSID on a node which again will create a lot of
> burden in IGP. The proposed way will have to be discussed in LSR, not in
> SPRING (see next comment).
>
>
> Note that [I-D.ietf-spring-segment-protection-sr-te-paths] could also work
> with BSIDs as long as BSID information of failed node is available in the
> control-plane of PLRs by whatever mechanism. I think this BSID handling is
> orthogonal to the proxy-forwarding controlplane behavior. The forwarding
> operations for BSID will have to be discussed more in details, we could not
> expect all HW to be able to do 3 or 4 lookups without any perf degradation.
>
>
>
> 1. The document is currently a bit borderline between SPRING and LSR as it
> talks in good details about IGP protocol extensions. If it's a SPRING doc, it
> should detail reqs for protocols but nothing beyond.
>
>
>
> Brgds,
>
> Stephane
>
>
> From: spring
> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>
> On Behalf Of
> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>
> Sent: jeudi 13 janvier 2022 11:19
> To: SPRING WG
> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>
> Subject: [spring] WG adoption call -
> draft-hu-spring-segment-routing-proxy-forwarding
>
> Dear WG,
>
> This message starts a 2 week WG adoption call, ending 27/01/2022, for
> draft-hu-spring-segment-routing-proxy-forwarding
> https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/__;!!NEt6yMaO-gk!TiIGZ1oWfUzj6AIX35pvSwyD9BhU_1E0xwkRheX14PjuGLhIolaoExk2oKTgLzsj$<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-hu-spring-segment-routing-proxy-forwarding*2F*3chttps*3A*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-hu-spring-segment-routing-proxy-forwarding*2F__*3B!!NEt6yMaO-gk!TiIGZ1oWfUzj6AIX35pvSwyD9BhU_1E0xwkRheX14PjuGLhIolaoExk2oKTgLzsj*24__*3BJQ!!NEt6yMaO-gk!Gp81jDYZ3hp9oK7AEli0aYgzF_rpD4qh844i3QpRQpiXqFnQ8gFASrQYxdoEmenRE1xqVEzcPGN9TrPR0BxCq7Yd1w*24%26data%3D05*7C01*7Chuaimo.chen*40futurewei.com*7C046e5196a53a4d62b00308dad1c99b90*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C638052961106546290*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*7C*7C*7C%26sdata%3D1Sgjfg5zxsLnekl4aV9D3JnUu3WU4UCOIo7GmfWbdOE*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSolJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!BV0Sh1dxfCHmVusFS32-Ww2sL1zKgGXb0Pucpe7tX-cWW7LAhCXT1cXG3X0fjVmmL-TS-TwuNwpHTsf2eMRST29X%24&data=05%7C01%7Chuaimo.chen%40futurewei.com%7C8ceda826b91249143bdc08dae384e59f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638072457210635496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OHZO2hK9zZ0pybb2feqAwL7aiikKSRtjMm%2Bbb1G6QD0%3D&reserved=0>>
>
> After review of the document please indicate support (or not) for WG adoption
> of the document to the mailing list.
>
> Please also provide comments/reasons for your support (or lack thereof) as
> this is a stronger way to indicate your (non) support as this is not a vote.
>
> If you are willing to work on or review the document, please state this
> explicitly. This gives the chairs an indication of the energy level of people
> in the working group willing to work on the document.
>
> Thanks!
Bruno, Jim, Joel
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
