Dear Brian,
Thank you very much for these detailed answers. They
give us clear direction for the next revision.
> There are two negotiation examples (the Briggs/Gray
> pair of ASAs, and the pfxm3.py simulation of RFC8992).
> But they are not quite 'targeted' because the server
> side doesn't care about the identity of the client.
That is a very good point, and it highlights an area
where our draft needs to be more explicit. In our
design, the Path Initiator performs M_DISCOVERY for each
path node individually, and uses the locator returned in
M_RESPONSE to match against the node-address field in
the pre-computed node-protection-info. This way, each
M_REQ_NEG carries only the protection state intended for
that specific node. We realize that this identity-aware
dispatching is not described clearly enough in the
current Section 5.1, and we will add this detail in the
next revision.
> Unless there is a performance problem, I believe that
> separate negotiations are better. Of course, if you
> were dealing with hundreds of nodes my answer might be
> different. It might be worth designing your objectives
> so that they can used in both models.
We agree, and this is very helpful guidance. Looking at
our CDDL definition, the "*" operator on
node-protection-info already allows both modes
structurally. However, the current example in Section
4.3 only shows the "all nodes packed together" form. In
the next revision, we plan to add a second example
showing the negotiation-mode form, where only a single
node-protection-info entry is included -- for instance,
the objective value sent specifically to node n2:
srv6-failover-value = [
[0x0000a, h1-addr, h2-addr, 3600000],
[[n1-sid, n2-sid, n3-sid, n4-sid, h2-sid],
[n1-addr, [b1-sid, b2-sid, b3-sid, h2-sid]],
[n2-addr, [b4-sid, b5-sid, h2-sid]]],
[n2-addr, 0, n1-addr, n3-addr,
[[b4-sid, b5-sid, h2-sid], b4-addr]]
]
This way readers can see both usage modes clearly. Does
this approach look right to you, or would you suggest
further restructuring the objective format?
> I think that flooding plus filtering can get very
> complicated, however.
> https://www.ietf.org/archive/id/
> draft-ietf-anima-grasp-distribution-12.html
> shows the complexity.
Thank you for this pointer. We will add it as an
informative reference and include a note in Section 5.1
stating that for large-scale deployments, the selective
flooding mechanisms defined in that draft could be used
as an alternative distribution method.
> That sounds correct to me. GRASP was not designed for
> high performance; it should not be expected to react
> at light speed to faults.
We will strengthen Section 3.1 based on this. Currently
it states the separation as two bullet points, but does
not explain the rationale. We plan to add text along
the lines of: "GRASP is designed for reliable
information distribution during path setup, but is not
intended for real-time fault reaction. Therefore, all
failure detection and failover execution MUST be
performed entirely in the data plane using pre-installed
forwarding state, without any GRASP signaling in the
failover path."
> That will be great. Don't hesitate to report any bugs
> you find!
We have started setting up graspy on Windows 11 with
Python 3.14. Our plan is to build an FPM-Initiator ASA
that iterates through path nodes, performs per-node
discovery and targeted negotiation, and an
FPM-Responder ASA that installs the received
node-protection-info into a simulated forwarding table.
We will share our progress and any issues we find.
Best regards,
Lintong Du
(on behalf of all co-authors)
Beijing University of Posts and Telecommunications
杜林潼
北京邮电大学/研博生/计算机学院（国家示范性软件学院）
北京
------------------ Original ------------------
From: "Brian E Carpenter"<[email protected]>;
Date: Tue, Mar 10, 2026 11:04 AM
To: "杜林潼"<[email protected]>; "Anima WG"<[email protected]>;
"draft-du-anima-srv6-failover-gra"<[email protected]>;
Subject: Re: I-D Action: draft-du-anima-srv6-failover-grasp-00.txt
Now to answer your other questions...
On 07-Mar-26 20:10, 杜林潼 wrote:
...
> We do have a couple of questions where your guidance would be
> particularly helpful:
>
> 1. In our design, the Path Initiator needs to distribute different
> node-protection-info to each node along the primary
path (each
> node receives its own role, upstream/downstream
neighbors, and
> backup path if applicable). We are using individual
GRASP
> negotiation sessions for this. Would you consider this
the
> idiomatic way to use GRASP for such per-node
configuration, or
> would you suggest an alternative approach such as using
flood
> with filtering?
Unless there is a performance problem, I believe that separate
negotiations are better. Of course, if you were dealing with hundreds
of nodes my answer might be different. It might be worth designing
your objectives so that they can used in both models.
I think that flooding plus filtering can get very complicated, however.
https://www.ietf.org/archive/id/draft-ietf-anima-grasp-distribution-12.html
shows the complexity.
> 2. For the SRv6 operational details — the bounce-back strategy is
> essentially a data plane fast reroute mechanism that
works in
> two phases: (a) in-flight packets are bounced upstream
to the
> nearest Anchor node upon failure detection, and (b) the
Anchor
> node re-encapsulates them onto a pre-computed backup
SRv6 path.
> GRASP is only used during the setup phase to distribute
the
> protection state, not during the actual failover. We
would be
> happy to provide a more detailed explanation of the
SRv6 aspects
> if that would be helpful.
That sounds correct to me. GRASP was not designed for high performance;
it should not be expected to react at light speed to faults.
>
> We will share our graspy-based simulation results once the prototype
> is ready. Thank you again for your encouragement and the excellent
> graspy tool.
That will be great. Don't hesitate to report any bugs you find!
Regards
Brian
>
> Best regards,
> Lintong Du
> (on behalf of all co-authors)
> Beijing University of Posts and Telecommunications
>
>
>
>
> 杜林潼
>
> 北京邮电大学/研博生/计算机学院（国家示范性软件学院）
>
> 北京
>
> ------------------ Original ------------------
> *From:* "Brian E Carpenter";
> *Date:* 2026年3月7日(星期六) 上午6:32
> *To:* "Anima WG"; "draft-du-anima-srv6-failover-grasp";
> *Subject:* Re: I-D Action: draft-du-anima-srv6-failover-grasp-00.txt
> Hi,
>
> I had a quick look at this draft and so far its definition of a GRASP
objective looks correct to me. I don't understand SRV6 operations well enough
to comment on the details of the use case.
>
> I'll just remind the authors that they could simulate the use case using
the demonstration implementation of of GRASP, open source at
https://github.com/becarpenter/graspy/
<https://github.com/becarpenter/graspy/>
>
> Regards/Ngā mihi
> Brian Carpenter
>
> On 02-Mar-26 03:21, [email protected]
<mailto:[email protected]> wrote:
> > Internet-Draft draft-du-anima-srv6-failover-grasp-00.txt is now
available.
> >
> > Title: Autonomic SRv6
Network Fast Failover Using Bounce-back Strategy with GRASP
> > Authors: Lintong Du
>
>
Xiangyang Gong
>
>
Xirong Que
>
>
Fang Deng
> > Name:
draft-du-anima-srv6-failover-grasp-00.txt
> > Pages: 15
> > Dates: 2026-03-01
> >
> > Abstract:
> >
> > This document specifies an autonomic
fast failover mechanism for SRv6
> > networks using a bounce-back
strategy. It uses GRASP to distribute
> > failover protection information,
enabling data plane fast reroute
> > without control plane reconvergence.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> >
https://datatracker.ietf.org/doc/draft-du-anima-srv6-failover-grasp/
<https://datatracker.ietf.org/doc/draft-du-anima-srv6-failover-grasp/>
> >
> > There is also an HTML version available at:
> >
https://www.ietf.org/archive/id/draft-du-anima-srv6-failover-grasp-00.html
<https://www.ietf.org/archive/id/draft-du-anima-srv6-failover-grasp-00.html>
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list -- [email protected]
<mailto:[email protected]>
> > To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
