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
