Pierre and Rob, Thanks for the clarification.
I guess I was expecting to see some of that discussion in the draft, but perhaps that is covered elsewhere. Anoop On Fri, Jun 6, 2014 at 9:09 AM, Rob Shakir <[email protected]> wrote: > Anoop, > > As Pierre says, the head-end is able to choose whether he would like > protection from a midpoint. This assumes that one advertises both > "protected" and "unprotected" segments within a network where there may be > a requirement for both, allowing the head-end to select the relevant > segment. This is roughly analogous to the behaviour of requesting FRR (or > not) when signalling a TE-LSP, and hence has the same security > characteristics from my perspective. > > It should be noted that _if_ all segments are advertised as protected (and > non-revertive/unprotected segments are not available) then this may > introduce more detailed per-LSP OAM requirements at the head-end to ensure > that it can react to a service which does not meet its performance > constraints during a period where local FRR is being utilised by a midpoint > on the path. > > Kind regards, > r. > > > > > On 6 Jun 2014, at 15:53, Pierre Francois <[email protected]> > wrote: > > > > Anoop, > > Well, we have this requirement to be able to have both approaches doable > at the same time on the same network... > > For example, in SR, you can encode configure your segments as to be > protected, or not. > > If you want local protection, configure segments to be locally protected. > If you want path protection, configure segments to not be locally > protected. > > If you need both for two different services, you'd configure both types > and pick the ones that match the service you need. > > Cheers, > > Pierre. > > > > On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani <[email protected]> wrote: > > Pierre, > > My question is more from a security standpoint. > > If a node is explicitly identified in the path and that node is down, is > it OK to route around it. > > I guess what I'm hearing you say is that it depends on what the network > operator has configured. They can choose to either discard all such > packets, or route all such packets around the failure, but they cannot > choose what it to be done on a per-packet basis. Do I have that right? > > Anoop > > > On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois <[email protected] > > wrote: > >> >> Anoop, >> >> You loose the traffic until the moment the ingress node falls back on >> another path. >> >> If you don't want to have to wait for that failover to happen, then your >> use-case is in another section than the one using path protection ;) >> >> Pierre. >> >> >> >> On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani <[email protected]> wrote: >> >> Thanks Pierre. >> >> What if the failed component is one of the explicitly identified hops? >> >> Anoop >> >> >> On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois < >> [email protected]> wrote: >> >>> >>> Hello Anoop, >>> >>> In path protection, section 2, the packets will be dropped until the >>> ingress node decides to stop using the failed path and failover. >>> >>> In all other sections, the packets are to be rerouted directly by the >>> nodes adjacent to the failed component. >>> >>> Cheers, >>> >>> Pierre. >>> >>> On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <[email protected]> >>> wrote: >>> >>> I have a question about this draft. >>> >>> In section 2, it has the following statement: >>> >>> >>> >>> >From a SPRING viewpoint, we would like to highlight the following >>> requirement: the two configured paths T1 and T2 MUST NOT benefit from >>> local protection. >>> >>> >>> >>> >>> But there is no such statement in subsequent sections. >>> >>> So suppose I have a data packet using SPRING to use path A - B - C. If >>> B is down, would such packets be discarded or would there be an attempt to >>> get it to C if one of the other methods for repair is configured? >>> >>> Anoop >>> >>> On Tue, May 13, 2014 at 9:35 AM, <[email protected]> wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Source Packet Routing in Networking >>>> Working Group of the IETF. >>>> >>>> Title : Use-cases for Resiliency in SPRING >>>> Authors : Pierre Francois >>>> Clarence Filsfils >>>> Bruno Decraene >>>> Rob Shakir >>>> Filename : draft-ietf-spring-resiliency-use-cases-00.txt >>>> Pages : 8 >>>> Date : 2014-05-12 >>>> >>>> Abstract: >>>> This document describes the use cases for resiliency in SPRING >>>> networks. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-00 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> spring mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/spring >>>> >>> >>> _______________________________________________ >>> spring mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/spring >>> >>> >>> >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> >> >> > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
