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

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

_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to