[spring] Re: Few more comments on draft-ietf-spring-sr-redundancy-protection

[Balázs Varga A <[e-mail]>]

Hi Luis,

Many thanks for the comments.

- MTU: yes, redundancy protection increases the packet size. It is the same as for other SRv6 tunnels. The size increase depends also on how many hops between the redundancy nodes are defined.

- End.R: right, the first redundancy node has some additional tasks to do. The flow identification at the first redundancy node is done based on the received packet header fields, and the result is added in the form of a Flow-ID to the ARG part of the End.R. Downstream redundancy nodes can identify simple the flows based on the Flow-ID value. The SeqNum is added by the first redundancy node and used by all the downstream redundancy nodes. The SeqNum is added also to the ARG part of the End.R. In order to avoid confusion the following change is proposed.
OLD TEXT
    Encapsulates flow identification and sequence number in packets if
    the two information is not carried in packets.
NEW TEXT
    Encapsulates flow identification and sequence number in SRv6 packets.
END

- SeqNum size: yes, this was discussed in DetNet and resulted in defining the 28 bit SeqNum format.

Thanks & Cheers
Bala'zs

From: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>
Sent: Friday, April 17, 2026 6:01 PM
To: spring <[e-mail]>
Cc: Deterministic Networking Discussion List <[e-mail]>; [e-mail]
Subject: Few more comments on draft-ietf-spring-sr-redundancy-protection

Dear all,

Sharing few more comments related to draft-ietf-spring-sr-redundancy-protection in SPRING but cc-ing DetNet because of the intersection of the redundancy/PREF concept (that is, no ordering in this case).


  *   It would be interesting to understand the potential impact on the MTU due to the fact of activating the redundancy protection while traversing the network. This could be a limiting factor, or at least condition the applicability to the need of defining an MTU size in the domain for being able to apply the solution.
  *   In section 4.1, for End.R it is mentioned that "Encapsulates flow identification and sequence number in packets if the two information is not carried in packets". But, how this is known? Adding some clarification could help.
  *   Sequence number size. I recall I raised this point during DetNet session in Madrid, and also commented in DetNet list (https://mailarchive.ietf.org/arch/msg/detnet/KoMjM68ZGtZ6fAONnHdpRCIoNs8/) Assuming SRv6 as technology for WAN deployments, it could be certain cases where replicating traffic in two high-speed links (e.g., 100 Gbps or higher) with different lengths in terms of hundreds of kms (for instance using different nation-wide links or submarine cables) could make this replication not working properly. As suggested in such mail to DetNet, adding some clarification to that fact would be necessary in my opinion (acknowledging that would not be the general case, but yet operationally important in my view).  I already proposed some text, but of course any other text would be ok.

Best regards

Luis

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição