Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 5 Jun 2014 11:51:44 -0700

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

---

From: Pierre Francois <[email-masked]>
Date: Fri, 6 Jun 2014 14:28:52 +0200

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-masked]> wrote:

> 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
> 
> 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.
> 
> Please note that it may take a couple of minutes from the time of submission

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 6 Jun 2014 07:30:42 -0700

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-masked]>
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.
>

---

From: Pierre Francois <[email-masked]>
Date: Fri, 6 Jun 2014 16:38:18 +0200

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-masked]> wrote:

> On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois <[email-masked]> wrote:
> 
> Hello Anoop, 
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 6 Jun 2014 07:45:23 -0700

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-masked]>
wrote:

> 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 Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois <[email-masked]
> > wrote:
>
>>
>> Hello Anoop,
>>

---

From: Pierre Francois <[email-masked]>
Date: Fri, 6 Jun 2014 16:53:54 +0200

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-masked]> wrote:

> 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-masked]> wrote:
> 
> Anoop, 
>

---

From: Rob Shakir <[email-masked]>
Date: Fri, 6 Jun 2014 17:09:53 +0100

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.

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 6 Jun 2014 09:41:15 -0700

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-masked]> 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.
>
>
>
>
> 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 Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois <[email-masked]
> > wrote:
>
>>
>> Anoop,
>>
>>> 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

---

From: Pierre Francois <[email-masked]>
Date: Fri, 6 Jun 2014 18:51:10 +0200

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-masked]> wrote:
> 
> Pierre and Rob,
> 
> I guess I was expecting to see some of that discussion in the draft, but perhaps that is covered elsewhere.
> 
> Anoop
> 
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 6 Jun 2014 10:40:38 -0700

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-masked]>
wrote:

>> It should be noted that _if_ all segments are advertised as protected
>> (and non-revertive/unprotected segments are not available) then this may

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 6 Jun 2014 23:51:00 +0000

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-masked]] On Behalf Of Pierre Francois
Sent: Friday, June 06, 2014 7:54 AM
To: Anoop Ghanwani
Cc: [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt

Anoop,

Cheers,

Pierre.

On Jun 6, 2014, at 4:45 PM, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>> wrote:

Pierre,

Anoop

On Fri, Jun 6, 2014 at 7:38 AM, Pierre Francois <[email-masked]<mailto:[email-masked]>> wrote:

Anoop,

Pierre.

On Jun 6, 2014, at 4:30 PM, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Pierre.

Anoop

On Fri, Jun 6, 2014 at 5:28 AM, Pierre Francois <[email-masked]<mailto:[email-masked]>> wrote:

Hello Anoop,

Cheers,

Pierre.

On Jun 5, 2014, at 8:51 PM, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>> wrote:

In section 2, it has the following statement:

local protection.

Anoop
On Tue, May 13, 2014 at 9:35 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

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/>.

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Rob Shakir <[email-masked]>
Date: Sat, 7 Jun 2014 08:30:39 +0100

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.

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 10 Jun 2014 02:14:55 +0000

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-masked]]
Sent: Saturday, June 07, 2014 12:31 AM
To: Gregory Mirsky
Cc: Pierre Francois; Anoop Ghanwani; [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt

Hi Greg,

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-masked]<mailto:[email-masked]>> wrote:

Hi Pierre,

                Regards,
                                Greg

From: spring [mailto:[email-masked]] On Behalf Of Pierre Francois
Sent: Friday, June 06, 2014 7:54 AM
To: Anoop Ghanwani
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-00.txt

Anoop,

Cheers,

Pierre.

Pierre,

Anoop

Anoop,

Pierre.

Thanks Pierre.

Anoop

Hello Anoop,

Cheers,

Pierre.

In section 2, it has the following statement:

local protection.

Anoop

Abstract:

---

From: Pierre Francois <[email-masked]>
Date: Tue, 10 Jun 2014 12:34:39 +0200

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-masked]> wrote:

> If authors are planning to change the wording then I’ll wait for the update.
>  
>                 Regards,
>                                 Greg