Hi Pierre,
clipped things we’ve already agreed on. Added note under GIM>> tag.

                Regards,
                                Greg

[snip]


o   Does local protection in SPRING network domain takes into consideration SID 
labels. If SID labels are not being considered when pre-calculating backup 
tunnels then it is possible that after the switchover end-to-end path fails. On 
the other hand, if SID labels being considered, then, in general case, 
intermediate node must maintain path information, which is not as Segment 
Routing paradigm being defined at this time.


Well now that the draft is not about solutions or specifics of SR, this is not 
a problem anymore :)

More seriously, yes, in SR, you have to pay attention to label allocation when 
installing your failover entries in the FIB. However I do not see why it leads 
to having intermediate nodes maintain path information.
Can you expand on this part of your comment?

GIM>> Link mode of local protection does not require any special consideration 
as the MP is the same next-hop node of the protected link. But for node mode of 
local protection special consideration must be given if SID functionality to be 
used. Consider case when the next-hop node has advertised SID that is used by 
some e2e paths that traverse the PLR and this node. As result, IMO, selection 
of the MP depends not only on next-next-hop node of the SR path but on 
availability of particular SID as well. Now we can make it more complex if the 
protected node owns not one but several SIDs. I think that we may easily avoid 
this complexity/mess by stating that only link mode local protection is 
applicable to SPRING domains and leave service protection/redundancy to 
Service/SFC OAM layer.

Cheers,

Pierre.


Regards,
                Greg
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to