Hi Xuesong, Mach, Fan, Some comments/questions on the proposal.
1. We don't need an additional "redundancy segment" for the replication semantics. Existing "replication segment" (draft-ietf-spring-sr-replication-segment) can be used as is, especially for the scenario where the original header already carries (FI, SN) information. 2. Even for the scenario where the (FI, SN) information needs to be added by the redundancy node, the existing "replication segment" can be enhanced to add the (FI, SN) information. 3. I wonder why (FI, SN) information is added as a TLV in the SRH. Would it be better to use DOH? For #1, and #2, reusing/enhancing existing replication segment has the following benefits: a. Reduce protocol/implementation work b. Reduce the amount of state in the network (the same P2MP tunnel can be used for both multicast traffic and unicast redundancy) b) can be achieved even with #2 (redundancy node needs to add (FI, SN) information): for SRv6, the semantics of adding (FI, SN) can be indicated by the arg part of the replication SID and for SR-MPLS it can be indicated by an additional label in front of the replication sid label. If using an addition label is a concern, then indeed a single label can be used to indicate both "add FI/SN information" and "replicate", but still the replication semantics can still be set up using the replication segment infrastructure. For SR-MPLS, where would you put the (FI, SN) information? Seems that GDFH (draft-zzhang-intarea-generic-delivery-functions) is a good option and that can be used for SRv6 as well (anything in DOH that is actually independent of IP could be extracted out to GDFH). Thanks. Jeffrey Juniper Business Use Only _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
