Hello Greg, Maybe a confusion comes from the fact that this sentence only applies to the case of that section. Section 5 mentions that the various approaches described in the doc should be applicable at the same time in a given network.
I'll try to clarify this. Pierre. On Jun 10, 2014, at 4:14 AM, Gregory Mirsky <[email protected]> wrote: > Hi Rob, > I think that it is about the same note in the Section 2 Path protection: > 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. > If authors are planning to change the wording then I’ll wait for the update. > > Regards, > Greg > From: Rob Shakir [mailto:[email protected]] > Sent: Saturday, June 07, 2014 12:31 AM > To: Gregory Mirsky > Cc: Pierre Francois; Anoop Ghanwani; [email protected] > Subject: Re: [spring] I-D Action: > draft-ietf-spring-resiliency-use-cases-00.txt > > Hi Greg, > > From my perspective, I do not see these as mutually exclusive - could you > point out the wording in the current draft(s) that implies such please? > > There is no restriction such that a head-end must select segments that are > not locally protected when implementing e2e protection - we see applications > whereby there will be a requirement for strict performance guarantees, such > that tolerating the variance introduced by local protection is unacceptable > (and hence the head-end selects non-revertive segments) - along with those > where such variance is tolerable (and hence protected segments are chosen). > It is simply up to the configuration of the head-end node for a particular > LSP as to how it chooses to provide protection. > > As you say, in the case where only e2e protection is implemented - then it’s > critical to consider how defects are detected, and what the delay in such > defects being detected is, such that the path-protection implemented is > suitable for the transported application. > > Kind regards, > r. > > On 7 Jun 2014, at 00:51, Gregory Mirsky <[email protected]> wrote: > > > Hi Pierre, > is my understanding correct that authors consider local and e2e protection in > SR to be mutually exclusive for given service path? I think that that may be > unnecessary limitation and recommendation of careful consideration and > coordination of defect detection times locally and e2e would suffice. > > Regards, > Greg > > From: spring [mailto:[email protected]] On Behalf Of Pierre Francois > Sent: Friday, June 06, 2014 7:54 AM > To: Anoop Ghanwani > Cc: [email protected] > Subject: Re: [spring] I-D Action: > draft-ietf-spring-resiliency-use-cases-00.txt > > > > 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
