Pierre, Re-reading the doc, it sounds like this is covered by the 5th bullet in Section 5.
Thanks, Anoop On Fri, Jun 6, 2014 at 9:51 AM, Pierre Francois <[email protected]> wrote: > > 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
