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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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<http://tools.ietf.org/>.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
