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]<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]
https://www.ietf.org/mailman/listinfo/spring
