Subject: [spring] follow-up answer on sr-redundancy-protection

From: "Yangfan (IP Standard)" <[email-masked]>
Date: Tue, 27 Jul 2021 07:09:14 +0000

Hi SPRING,

Due to limited presentation time today, I’d like to give the clarification to the questions brought by Greg at IETF 110 and 111.

From today’s meeting minutes:
Suggest to analyze why this is more beneficial than just 1+1 protection when you select the working source and protection source and do the switchover not per packet but source.

I first compare the two mechanisms in case people need background.
The common part of 1+1 protection and redundancy protection is that source duplicates the packets and sends two or multiple replicas via different disjoint paths.
The difference is,
regarding 1+1 protection, receiver only receives one copy of traffic from either path, which is determined by a local state machine on receiver.
regarding redundancy protection, two copies of traffic from both paths are received by receiver, and receiver eliminates the redundant packets per packet.

The benefit of redundancy protection is obvious. Since 1+1 protection needs switchover either at source or sink, when there is a failure on either path, the failure detection and switchover could cause the packet loss. With redundancy protection, failures on either path will not result in any packet loss, which brings significant value to service needs ultra reliable transmission.

Thanks again for the discussion.

Regards,
Fan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 27 Jul 2021 08:37:04 +0000

Hello Fan;

I read something else there too; the question whether we need to do PREOF inside the network (IOW a complex mesh or ring chain of replication and elimination) or whether it is enough to do it only end to end (IOW live-live only).

When we started DetNet, many people came from TP style of operation and pushed for live-live only. But the discussion evolved and now it is recognized that DetNet - and even more, RAW - needs the capability to do PREOF and flow aggregation inside the DetNet domain as opposed to from the source or the ingress PE only. This is what fig 1 of RFC 8655 illustrates, what is discussed in https://www.ietf.org/archive/id/draft-ietf-raw-architecture-00.html#name-end-to-end-protection-in-a-, and what RPL installs with SR-VIOs in https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection-18#section-7.

Whether to do live-live end to end or a more complex design depends on:
- the individual and aggregate reliability of the links (including chances of SRLG)
- the speed of end-to-end reaction (OAM/BFD + rerouting), which has to do with the speed of the links vs. the acceptable losses in a row (think of using this vs. ARQ)
- the criticality of the function (applicability to safety operations with a risk of explosion and/or lives at stake)

My reading of the question is whether the SPRING use cases can live with live-live only, or whether more complex structures with intermediate PREOF are in scope as well.

Keep safe;
Pascal

From: spring <[email-masked]> On Behalf Of Yangfan (IP Standard)
Sent: mardi 27 juillet 2021 9:09
To: spring <[email-masked]>
Cc: [email-masked]
Subject: [spring] follow-up answer on sr-redundancy-protection

Hi SPRING,

Regards,
Fan