Anoop, If this was unclear, I'll try to make the point better in next revision.
Regards, Pierre. Sent from my iPhone > On Jun 6, 2014, at 6:41 PM, Anoop Ghanwani <[email protected]> wrote: > > 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
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
