Hi Yakov, thanks for the comment. See below.
On Mar 24, 2014, at 7:31 PM, Yakov Rekhter wrote: > Alvaro, > >> Hi! >> >> This message officially starts the call for adoption for >> draft-francois-spring-resiliency-use-case. >> >> Please indicate your position about adopting this use cases draft >> by end-of-day on March 27, 2014. >> >> http://tools.ietf.org/html/draft-francois-spring-resiliency-use-case >> >> Thanks! >> >> Alvaro. > > This draft covers more than just use cases, but describes a solution. > E.g., in section 2: > > This is achieved by > resetting the B-flag in the related AdjSID's as per the IGP > extensions defined in [3]. > > and in section 3: > > An SR solution aimed at supporting these requirements is defined in > [2]. > > and in section 5: > > Let us illustrate this for adjacency segments with the following > example. > > o Node C is configured with 3 adjacency segments for the connected > interface to D: AdjSID(CD1), AdjSID(CD2) and AdjSID(CD3) > o SR Flow F1: from A to E over segment list > {NodeSID(C), AdjSID(CD1), NodeSID(E)} > o SR Flow F2: from F to I over segment list > {NodeSID(C), AdjSID(CD2), NodeSID(I)} > o SR Flow F3: from G to Z over segment list > {NodeSID(C), AdjSID(CD3), NodeSID(Z)} > o Node C is configured with a distinct protection technique for each > adjacency segment. AdjSID(CD1) is configured without protection, > AdjSID(CD2) is configured to benefit from management-free local > protection and AdjSID(CD3) is configured for managed local > protection over the path {AdjSID(CH), AdjSID(HD)} > > Such a co-existence is partially supported by the SR IGP extensions > [ref tbd] > o Multiple adjacency segments can be advertised for the same > adjacency > o The non-protected property of AdjSID(CD1) is signalled by a reset > B flag. > o The protected property of AdjSID(CD2) and AdjSID(CD3) are > signalled by a set B flag. > > The SR IGP extension should be extended to discreminate between > AdjSID(CD2) and AdjSID(CD3). A single flag could be defined (managed > path vs fully automated). > > The SPRING resiliency use case document has to elaborate each use > case in sufficient details that we could each read it and agree on > how the functionality would be accomplished, but without describing > the actual solutions. I agree. We will address your comment in the next revision (work in progress) very soon. Thanks. s. > > Yakov. > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
