Hi SPRING,
Thank you for the comments to I-D.geng-spring-redundancy-policy. Some follow-up
explanations to the questions in meeting.
1. Redundancy at Candidate path level or SID-List level?
There are two reasons to define the redundancy paths at SID-List level.
Firstly, looking at the use cases, e2e load balance and redundancy protection
has very limited chance to be used together. If there is a partial network
needs load balancing, loose path can be used. Secondly, there is a scenario
shown in the slide, (due to the limited time I didn't emphasize and explain it
in the session), where the redundancy protection is protected by the third best
effort path in green. It actually provides different levels of protections to
the service.
As discussed in meeting, either way is doable for redundancy policy. IMHO the
choice is more dependent on the scenarios and requirements.
2. Redundancy SID acts as the BSID of Redundancy Policy
In I-D.ietf-spring-redundancy-protection, Redundancy SID is defined as the
variation of Binding SID (BSID) and the operations defined as:
Redundancy Segment is associated with service instructions,
indicating the following operations:
* Steers the packet into the corresponding redundancy policy
* Encapsulates flow identification and sequence number in packets if
the two information is not carried in packets
* Packet replication and segment encapsulation based on the
information of redundancy policy, e.g., the number of replication
copies, an ordered list of segments with a topological instruction
Thanks again for the comments.
Best regards,
Fan
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
