Robert, Thanks for the clarification :)
Greg, There are operators who want to have the network provide such protection. You mind if I leave such approaches in the use-case doc, and we re-raise such very relevant complexity/mess questions when solution drafts are discussed? Cheers, Pierre. On Apr 3, 2014, at 11:01 PM, Robert Raszuk <[email protected]> wrote: > Hi Greg & Pierre, > > 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. > > > > I think you are both right :) > > I think what Greg you are refering to is state of the repair "paths" in > regards to IGP topology which clearly is required by all node protection > solutions. > > Contrary what I think Pierre consider as "path" is the end to end traffic > flow paths which would normally result in 100s or 1000s LSPs state - that > clearly is not required in SR node protection. > > So what may be helpful is to rather then overloading term "path" here > redefine it for the purpose of this discussion into IGP topology state (as > example). > > Cheers, > R. > > > > > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
