Subject: [spring] I-D Action: draft-francois-spring-resiliency-use-case-01.txt

From: [email-masked]
Date: Tue, 01 Apr 2014 05:39:45 -0700

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-francois-spring-resiliency-use-case-01.txt
	Pages           : 6
	Date            : 2014-04-01

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-francois-spring-resiliency-use-case/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-francois-spring-resiliency-use-case-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-francois-spring-resiliency-use-case-01

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/

---

From: Pierre Francois <[email-masked]>
Date: Tue, 1 Apr 2014 14:45:55 +0200

Hello everyone, 

We seemed to have some form of consensus on the relevance of the draft, but we also received multiple comments 
on the list, mostly asking to remove references to solutions from the document. 

Here comes an update to the draft trying to satisfy these comments.

Cheers, 

Pierre.

Begin forwarded message:

> From: [email-masked]
> Subject: I-D Action: draft-francois-spring-resiliency-use-case-01.txt
> Date: April 1, 2014 2:39:45 PM GMT+02:00
> To: [email-masked]
> Cc: [email-masked]
> Reply-To: [email-masked]
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 2 Apr 2014 07:24:59 -0700

Pierre,

> Here comes an update to the draft trying to satisfy these comments.

The update certainly addresses my comments wrt mixing use case
and solution. Thanks !

I have few more comments on the update.

> 3. Management-free local protection
> 
>    An alternative protection strategy consists in management-free local
>    protection.
> 
>    For example, a PW from C to E, transported over the shortest path to
>    E provided by the SPRING architecture, benefits from management-free
>    local protection by having each node along the path (e.g.  C and D)
>    automatically pre-compute and pre-install a backup path for the
>    destination E. Upon local detection of the failure, the traffic is
>    repaired over the backup path in sub-50msec.
> 
>    The backup path computation should support the following
>    requirements:
> 
>    o  100% link, node, and SRLG protection in any topology
>    o  Automated computation by the IGP
>    o  Selection of the backup path such as to minimize the chance for
>       transient congestion and/or delay during the protection period, as
>       reflected by the IGP metric configuration in the network.
> 
> 
> 4.  Managed local protection
> 
>    There may be cases where a management free repair does not fit the
>    policy of the operator.  For example, the operator may want the
>    backup path to end at the next-hop (or next-next-hop for node
>    failure) hence excluding IPFRR/LFA types of backup path.  Also, the

Such a backup path could be automatically pre-computed and pre-installed,
providing the management-free local protection. 

>    operator might want to tightly control the backup path to the next-
>    hop: for the destination Z upon the failure of link CD, the backup
>    path CGHD might be desired while the backup paths CGD and CHD are
>    refused.
> 
>    The protection mechanism must support the explicit configuration of
>    the backup path either under the form of high-level constraints (end
>    at the next-hop, end at the next-next-hop, minimize this metric,
>    avoid this SRLG...) or under the form of an explicit path. 

It seems that the key distinction between 3 and 4 is that 3 relies
on LFA (and its variations), while 4 relies on building link/node
bypasses. Both LFA-based protection, and protection based on
link/node bypasses could be fully automated. It is true however,
that with link/node bypasses the operator, if desired, could have
a fairly detailed control over the bypass.

With this in mind I would suggest to change the title of Section 3
to something like "LFA-based local protection", Section 4
to something like "Local protection based on link/node bypasses",
and also change the first sentence in section 4 to something like
the following:

    There may be cases where an LFA-based protection local protection
    does not fit the policy of the operator. 

Yakov.

---

From: Pierre Francois <[email-masked]>
Date: Wed, 2 Apr 2014 18:28:27 +0200

Hello Yakov, 

> providing the management-free local protection.

Indeed. I'm getting the feeling that the next-hop/next-next-hop example of section 4 is not well 
chosen for what we were trying to achieve :)

The use case of section 4 is basically: Give freedom to the operator on the definition of the repair path. 
We say that SPRING should allow the operator to define the protection he wants with the 
precision that he needs. More on this below, as it's related with your other comments. 

> bypasses.

Mmm, it was more: section 3 relies on automated protection established by the router, as experience showed
that it most often does the job, while section 4 relies on operator input to the router, in order to achieve a protection path that better fits his policy.

> Both LFA-based protection, and protection based on

Similarly to the link/node bypass approach, there are ways to provide more detailed control 
in some IP-FRR variants.  

>    does not fit the policy of the operator.

Based on your comments and mine, I would suggest the following ToC, as I think it 
unifies our views on the topic:

1. Path protection

2. Unmanaged local protection

2.1 Shortest path based / IP-FRR variants 
2.2 Automated link/node bypass
(as per your comment that link/node bypasses provide an unmanaged solutions)

3. Managed local protection

3.1 managed shortest path based protection
(allowing for constraints on the repair brought by the IP-FRR machinery, with the level of granularity
as currently described in the doc. )

3.2 managed link/node bypass based protection
(allowing for the detailed control over the bypass, as you mentioned)

Does that make sense to you?

Thanks a lot for your feedback, 

Pierre.

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

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 2 Apr 2014 09:44:57 -0700

Pierre,

> chosen for what we were trying to achieve :)

Correct :-)

> that it most often does the job, while section 4 relies on operator input 
> to the router, in order to achieve a protection path that better fits 
> his policy.
> 
> Similarly to the link/node bypass approach, there are ways to provide 
> more detailed control in some IP-FRR variants.  
> 
> Based on your comments and mine, I would suggest the following ToC, as 
> I think it unifies our views on the topic:
> 
> 1. Path protection
> 
> (allowing for constraints on the repair brought by the IP-FRR machinery, 
> with the level of granularity as currently described in the doc. )
> 

Yes, it does make sense. The ToC you proposed above is fine.

Yakov.

---

From: Pierre Francois <[email-masked]>
Date: Wed, 2 Apr 2014 18:53:42 +0200

Yakov, 

Okay I'll stick to the proposed ToC for rev -02. 
( and put a better example in former section 4 ;) )

Cheers, 

Pierre.