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 <[email protected]>
Sent: Friday, April 17, 2026 6:01 PM
To: spring <[email protected]>
Cc: Deterministic Networking Discussion List <[email protected]>;
[email protected]
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
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
