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
