Hi Sasha, et al.,
many thanks for the great discussion. Please correct me if my recollection
is not accurate, but at the time of RFC 4090 it was agreed, that a trigger
to local protection may be in fact a false negative and, as a result, the
protection switchover is suboptimal. I understand that
Thanks,
Some how I had missed these drafts – I will go through in further detail and
then potentially comment more. My bad for missing them and appreciate the
pointers.
Thanks
Andrew
From: Robert Raszuk
Sent: Monday, 2 December 2019 13:14
To: Andrew Alston
Cc: Shraddha Hegde ; Alexander
I encourage you to read those two documents:
https://tools.ietf.org/html/draft-akiya-bfd-seamless-sr-04
https://tools.ietf.org/html/draft-ali-spring-bfd-sr-policy-02
Cheers,
R.
On Mon, Dec 2, 2019 at 11:06 AM Andrew Alston <
andrew.als...@liquidtelecom.com> wrote:
> Robert – actually I
Robert – actually I disagree.
Because to protect the paths you need the node protection on intermediate nodes
due to lack of state – the headend has no way to actually protect an end to end
path outside of S-BFD steered over the path to test end to end reachability and
if you get an
On Mon, Dec 2, 2019 at 10:28 AM Andrew Alston <
andrew.als...@liquidtelecom.com> wrote:
Currently the biggest issue that I see with S-BFD based protection – which
> is something we use in production is as follows:
>
>
>
> Unless I’m mistaken – there is absolutely no way to tie S-BFD based
>
Currently the biggest issue that I see with S-BFD based protection - which is
something we use in production is as follows:
Unless I'm mistaken - there is absolutely no way to tie S-BFD based protection
with BGP injected SR-TE pathing
Node validation as defined in the SR-TE drafts is limited to
Sasha,
We are in agreement on separating the trigger from the protection mechanism..
> In any case I think that it woyld make sense to separate the protection
> scheme proposed in the draft from specific triggers for its activation
> >similar to how this has been done in MPLS Egress Protection
Shraddha,
Lots of thanks for athe tesponse.
I probably did not express myself clearly enough. I will try to fix thst now,
and I apologise in advance for a long email.
I have not been speaking about end-yo-end protecyion, only about local
protection against failure of an intermediate (a.k.a.
Robert/Sasha,
S-BFD based mechanism is head-end triggered protection. It is not a local
protection.
S-BFD mechanism is orthogonal to the mechanism described in this draft and an
operator can
choose what kind of protection makes more sense to his/her network.
In many cases, node-protecting
And coming back to the draft in question:
I think that it is about thecprotection action itself, anf this action may be
triggered by different events.
This approach has been taken in the MPLS Egress Protection
Robert,
On the second thought, for the purpose of this draft (i.e. in the scope of SR)
it is possible to implement your suggestion by running S-BFD sessions between
R7 (as the initiator) and each other adjacency of R8 (acting as Reflectors) of
a SR policy with list of two SIDs:
- protected
Robert,
Lots of thanks for a prompt response.
I respectfully disagree with your statement that BFD implementation is usually
offloaded to the HW of the ingress line card. I do not think this can wor for
MH BFD sessions because the ingress and egress line cards are not known in
advance and
Hi Sasha,
On the surface your suggestion may look cool - but if you zoom in - I do
not think it will work in practice.
See - one of the biggest value of BFD is its offload to line card's
hardware. And in most cases it is ingress line card to the box. So if you
instruct such hardware to respond
Shraddha, Robert and all,
Regarding Robert's question:
I wonder if multi-hop IP BFD session with addresses used as /32 (or /128)
prefixes serving as Nose SIDs of R8 and R7 respectively could be used as such a
trigger by R7? Such a session would not respond to link failures, and I find it
14 matches
Mail list logo
