Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks
draft-ietf-spring-resiliency-use-cases-12

[Ballot comment]
I have a question which is probably simply the result of not having had time to read all spring docs in detail: Can you maybe indicate how the requirements at the end of section 2 have been addressed in the spring architecture doc?

And another question on section 3: Wouldn't it also make sense to have a mechanism that reports if local repair was used and respectively the traffic was not routed over the indicated path but a different one?

And another comment on section 2: You write that you need a way to check the liveness of a path if used for primary and backup, however, this is also true for the case where the two paths are used with ECMP as it usually doesn't help you that much if you only receive half of your packets. Only if you send all packets over both paths, you don't need a active check, however, it should be mentioned that this also needs more capacity and can therefore cause unnecessary congestion.

[Ballot comment]
I agree with Ben's point about RFC 2119/8174 requirements keyword usage. For example, I'm looking at the MUST NOT in

  A first protection strategy consists in excluding any local repair
  but instead use end-to-end path protection where each SPRING path is
  protected by a second disjoint SPRING path.  In this case local
  protection MUST NOT be used.

and wondering why that's normative. I would have guessed that the point was, "if you use local protection, you're not carrying out the end-to-end path protection strategy that this section describes", but that isn't an RFC 2119/8174 interoperation keyword thing. What am I missing here?

I agree with Adam's confusion about

  Usually, in a normal routing protocol operations, microloops do not
  last long enough and in general they are noticed during the time it
  takes for the network to converge.

I assumed that this was supposed to say something like

  Usually, in a normal routing protocol operations, microloops do not
  last long enough to be noticed during the time it
  takes for the network to converge.

but the current text isn't clear.

[Ballot comment]
- Requirements Language: The 2119 keywords in this draft are not used in the sense of RFC 2119. That RFC talks explicitly about interoperability among protocol implementations. This draft uses them to define requirement for protocol and architecture design. That's not necessarily a problem, but please change the Requirements Language section to describe the actual usage.

-2, third paragraph from end:    "o  SPRING architecture MUST provide a way to compute paths that MUST NOT be protected by local repair techniques..."
The MUST NOT seems a statement of fact. Consider something to the effect of "... compute paths that are not protected by local repair techniques..."

[Ballot comment]
I *think* I found a minor issue. Section 5 contains the following text:

  Usually, in a normal routing protocol operations, microloops do not
  last long enough and in general they are noticed during the time it
  takes for the network to converge.

I'm assuming this is intended to say "...are not noticed..."?

[Ballot comment]
Some redundancy in the intro first two paragraphs.:

  This document reviews various use cases for the protection of
  services in a SPRING network.  The terminology used hereafter is in
  line with [RFC5286] and [RFC5714].

  This document reviews various use cases for the protection of
  services in a SPRING network.

[Ballot comment]
  As a reminder, one of the majors network operator requirements is
  path disjointness capability.  Network operators have deployed
Nit: major



  A first protection strategy consists in excluding any local repair
  but instead use end-to-end path protection where each SPRING path is
  protected by a second disjoint SPRING path.  In this case local
Nits:
"consists of" and "instead uses"



  path.  As a requirement, the two paths MUST be disjoint in their
  links, nodes or shared risk link groups (SRLGs).
Do you mean to say that this fulfills that requirement? Or is this an additional requirement that isn't provided by the topology given.



  o  SPRING architecture MUST provide a way to compute paths that MUST
      NOT be protected by local repair techniques (as illustrated in the
      example of paths T1 and T2).
This MUST NOT is kind of unclear. Are you computing paths that will not otherwise be protected? Are you computing paths in such a way that they will not be protected?



  This section describes two alternatives providing local protection
  without requiring operator management, namely bypass protection and
These are alternative strategies to the one described in S 2?



  For example, a demand from A to Z, transported over the shortest
  paths provided by the SPRING architecture, benefits from management-
"demand"? I would have assumed you meant "packet" or "datagram" here, but maybe I am misreading.



  destination Z.  Upon local detection of the failure, the traffic is
  repaired over the backup path in sub-50 milliseconds.  When primary
  path comes back up, the operator either allows for an automated
Nit: "When the primary"



  an automated reversion of the traffic onto the primary path or
  selects an operator-driven reversion.
Why would you want the mechanism in S 3.1 rather than S 3.2?



  of their topologies.  Detecting microloops can be done during
  topology computation (e.g.: SPF computation) and therefore
  microloops-avoidance techniques may be applied.  An example of such
Nit: "e.g., SPF"



  network state.  Traditionally, the lack of packet steering capability
  made difficult to apply efficient solutions to microloops.  A SPRING
  enabled router could take advantage of the increased packet steering
Nit: "made it difficult"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-spring-resiliency-use-cases-08.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: stephane.litkowski@orange.com, spring@ietf.org, draft-ietf-spring-resiliency-use-cases@ietf.org, spring-chairs@ietf.org, aretana@cisco.com, Stephane Litkowski
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Resiliency use cases in SPRING networks) to Informational RFC


The IESG has received a request from the Source Packet Routing in
Networking WG (spring) to consider the following document:
- 'Resiliency use cases in SPRING networks'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-05-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document identifies and describes the requirements for a set of
  use cases related to network resiliency on Segment Routing (SPRING)
  networks.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ballot/


No IPR declarations have been submitted directly on this I-D.

=== AD Review of draft-ietf-spring-resiliency-use-cases-08 ===

Dear authors:

The Abstract says that this document “identifies and describes the requirements for a set of use cases”.  As such, this document should then focus on the presentation of those use cases that will help in the definition of the spring architecture – which means that the details of such architecture or solution should not be pre-supposed.  My comments below are based on this interpretation – where I will ask you to please take out any assumption/reference to the architecture/solution.
I realize that the spring architecture has already been defined, and that implementations are available, making it harder to ignore what is already out there.  However, from a procedure point of view, this document should have ideally been developed *before* any work was done on the architecture/solution.  It is not necessary to justify publication, or even talk about the current WG charter (which includes documents like this one) – as you will see below, the changes required are minimum.
In this case, it seemed easier to include the document text and interleave comments.  Please see below.

I am starting the IETF Last Call – you can take my comments as part of that process.  As discussed before, I will progress all the use case documents at the same time to the IESG.
Thanks!!
Alvaro.



2      Network Working Group                                  C. Filsfils, Ed.
3      Internet-Draft                                          S. Previdi, Ed.
4      Intended status: Informational                      Cisco Systems, Inc.
5      Expires: May 1, 2017                                        B. Decraene
6                                                                        Orange
7                                                                      R. Shakir
8                                                                        Google
9                                                              October 28, 2016

11                      Resiliency use cases in SPRING networks
12                    draft-ietf-spring-resiliency-use-cases-08

14      Abstract

16        This document identifies and describes the requirements for a set of
17        use cases related to network resiliency on Segment Routing (SPRING)
18        networks.

20      Requirements Language

22        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
23        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
24        document are to be interpreted as described in RFC 2119 [RFC2119].

26      Status of This Memo

28        This Internet-Draft is submitted in full conformance with the
29        provisions of BCP 78 and BCP 79.

31        Internet-Drafts are working documents of the Internet Engineering
32        Task Force (IETF).  Note that other groups may also distribute
33        working documents as Internet-Drafts.  The list of current Internet-
34        Drafts is at http://datatracker.ietf.org/drafts/current/.

36        Internet-Drafts are draft documents valid for a maximum of six months
37        and may be updated, replaced, or obsoleted by other documents at any
38        time.  It is inappropriate to use Internet-Drafts as reference
39        material or to cite them other than as "work in progress."

41        This Internet-Draft will expire on May 1, 2017.

43      Copyright Notice

45        Copyright (c) 2016 IETF Trust and the persons identified as the
46        document authors.  All rights reserved.

48        This document is subject to BCP 78 and the IETF Trust's Legal
49        Provisions Relating to IETF Documents
50        (http://trustee.ietf.org/license-info) in effect on the date of
51        publication of this document.  Please review these documents
52        carefully, as they describe your rights and restrictions with respect
53        to this document.  Code Components extracted from this document must
54        include Simplified BSD License text as described in Section 4.e of
55        the Trust Legal Provisions and are provided without warranty as
56        described in the Simplified BSD License.

58      Table of Contents

60        1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
61        2.  Path Protection . . . . . . . . . . . . . . . . . . . . . . .  4
62        3.  Management-free Local Protection  . . . . . . . . . . . . . .  5
63          3.1.  Management-free Bypass Protection . . . . . . . . . . . .  5
64          3.2.  Management-free Shortest Path Based Protection  . . . . .  6
65        4.  Managed Local Protection  . . . . . . . . . . . . . . . . . .  6
66          4.1.  Managed Bypass Protection . . . . . . . . . . . . . . . .  7
67          4.2.  Managed Shortest Path Protection  . . . . . . . . . . . .  7
68        5.  Loop Avoidance  . . . . . . . . . . . . . . . . . . . . . . .  8
69        6.  Co-existence of multiple resilience techniques in the same
70            infrastructure  . . . . . . . . . . . . . . . . . . . . . . .  8
71        7.  Security Considerations . . . . . . . . . . . . . . . . . . .  9
72        8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  9
73        9.  Manageability Considerations  . . . . . . . . . . . . . . . .  9
74        10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  9
75        11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
76        12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
77          12.1.  Normative References . . . . . . . . . . . . . . . . . .  10
78          12.2.  Informative References . . . . . . . . . . . . . . . . .  10
79        Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

81      1.  Introduction

83        SPRING aims at providing a network architecture supporting services
84        with tight Service Level Agreements (SLA) guarantees
85        [I-D.ietf-spring-segment-routing].  This document reviews various use
86        cases for the protection of services in a SPRING network.

The first sentence talks about the architecture.


88        The resiliency use cases described in this document can be applied
89        not only to traffic that is forwarded according to the SPRING
90        architecture but also to traffic that originally is forwarded using
91        other paradigms such as LDP signalling or pure IP traffic (IP routed
92        traffic).

I’m not sure what this paragraph tries to say about the applicability of the use cases; it sounds like they apply to everything: spring networks, LDP networks and IP routed traffic.


94        Three key alternatives are described: path protection, local
95        protection without operator management and local protection with
96        operator management.

98        Path protection lets the ingress node be in charge of the failure
99        recovery, as discussed in Section 2.

101        The rest of the document focuses on approaches where protection is
102        performed by the node adjacent to the failed component, commonly
103        referred to as local protection techniques or Fast Reroute
104        techniques.

106        In Section 3 we discuss two different approaches providing unmanaged
107        local protection, namely link/node bypass protection and shortest
108        path based protection.

110        Section 4 illustrates a case allowing the operator to manage the
111        local protection behavior in order to accommodate specific policies.

113        In Section 5 we discuss the opportunity for the SPRING architecture
114        to provide loop-avoidance mechanisms, such that transient forwarding
115        state inconsistencies during routing convergence do not lead into
116        traffic loss.

118        The purpose of this document is to illustrate the different
119        approaches and explain how an operator could combine them in the same
120        network (see Section 6).  Solutions are not defined in this document.

I thought the purpose was to present use cases.


122                              B------C------D------E
123                              /|      | \  / | \  / |\
124                            / |      |  \/  |  \/  | \
125                            A  |      |  /\  |  /\  |  Z
126                            \ |      | /  \ | /  \ | /
127                              \|      |/    \|/    \|/
128                              F------G------H------I

130                            Figure 1: Reference topology

132        We use Figure 1 as a reference topology throughout the document.
133        Following link metrics are applied:

135          Link metrics are bidirectional.  In other words, the same metric
136          value is configured at both side of each link.

138          Links from/to A and Z are configured with a metric of 100.

140          CH, GD, DI and HE links are configured with a metric of 6.

142          All other links are configured with a metric of 5.

Because some terms are used for which people may not be completely familiar (local repair, disjoint path, local protection, SRLG, etc.), please add a reference to terminology.  Rfc5286/rfc5714 might be good Informative references (??).

NEW>
The terminology used in this document is in line with [rfc…].


144    2.  Path Protection


146        A first protection strategy consists in excluding any local repair
147        but instead use end-to-end path protection where each SPRING path is
148        protected by a second disjoint SPRING path.  In this case local
149        protection MUST NOT be used.

151        For example, a Pseudo Wire (PW) from A to Z can be "path protected"
152        in the direction A to Z in the following manner: the operator
153        configures two SPRING paths T1 (primary) and T2 (backup) from A to Z.

155        The two paths maybe used concurrently or as a primary and backup path
156        where the secondary path is used when the primary failed.

s/maybe/may be

158        T1 is established over path {AB, BC, CD, DE, EZ} as the primary path
159        and T2 is established over path {AF, FG, GH, HI, IZ} as the backup
160        path.  As a requirement, the two paths MUST be disjoint in their
161        links, nodes or shared risk link groups (SRLGs).

163        In the case of primary/backup paths, when the primary path T1 is up,
164        the packets of the PW are sent on T1.  When T1 fails, the packets of
165        the PW are sent on backup path T2.  When T1 comes back up, the
166        operator either allows for an automated reversion of the traffic onto
167        T1 or selects an operator-driven reversion.  Typically, the
168        switchover from path T1 to path T2 is done in a fast reroute fashion
169        (e.g.: sub-50 milliseconds range) but depending on the service that
170        needs to be delivered, other restoration times may be used.

172        It is essential that the primary and backup path benefit from an end-
173        to-end liveness monitoring/verification.  The method and mechanisms
174        that provide such liveness check are outside the scope of this
175        document.

177        There are multiple options for liveness check, e.g., path liveness
178        where the path is monitored at the network level (either by the head-
179        end node or by a network controller/monitoring system).  Another
180        possible approach consists of a service-based path monitored by the
181        service instance (verifying reachability of the endpoint).  All these
182        options are given here as examples.  While this document does express
183        the requirement for a liveness mechanism, it does not mandate, nor
184        define, any specific one.

186        From a SPRING viewpoint, we would like to highlight the following
187        requirements:

189        o  SPRING architecture MUST provide a way to compute paths that MUST
190          NOT be protected by local repair techniques (as illustrated in the
191          example of paths T1 and T2).

193        o  SPRING architecture MUST provide a way to instantiate pairs of
194          disjoint paths on a topology and based on a protection strategy
195          (link, node or SRLG protection) and allow the validation or re-
196          computation of these paths upon network events.

s/paths on a topology and based on a protection/paths on a topology based on a protection


198        o  The SPRING architecture MUST provide end-to-end liveness check of
199          SPRING based paths.

201    3.  Management-free Local Protection

203        This section describes two alternatives providing local protection
204        without requiring operator management, namely bypass protection and
205        shortest-path based protection.

207        For example, a demand from A to Z, transported over the shortest
208        paths provided by the SPRING architecture, benefits from management-
209        free local protection by having each node along the path
210        automatically pre-compute and pre-install a backup path for the
211        destination Z.  Upon local detection of the failure, the traffic is
212        repaired over the backup path in sub-50 milliseconds.

214        The backup path computation SHOULD support the following
215        requirements:

217        o  100% link, node, and SRLG protection in any topology.

219        o  Automated computation by the IGP.

221        o  Selection of the backup path such as to minimize the chance for
222          transient congestion and/or delay during the protection period, as
223          reflected by the IGP metric configuration in the network.

225    3.1.  Management-free Bypass Protection

227        One way to provide local repair is to enforce a fail-over along the
228        shortest path around the failed component.

230        In case of link protection, the point of local repair will create a
231        repair path avoiding the protected link and merging back to primary
232        path at the nexthop.

234        In case of node protection, the repair path will avoid the protected
235        node and merge back to primary path at the next-nexthop.

237        In case of SRLG protection, the repair path will avoid members of the
238        same SRLG of the protected link and merge back to primary path just
239        after.

s//…avoid members of the same group and merge…


241        In our example, C protects destination Z against a failure of CD link
242        by enforcing the traffic over the bypass {CH, HD}. The resulting end-
243        to-end path between A and Z, upon recovery against the failure of CD,
244        is depicted in Figure 2.

246                              B * * *C------D * * *E
247                              *|      | *  / * \  / |*
248                            * |      |  */  *  \/  | *
249                            A  |      |  /*  *  /\  |  Z
250                            \ |      | /  * * /  \ | /
251                              \|      |/    **/    \|/
252                              F------G------H------I

254                    Figure 2: Bypass protection around link CD

256    3.2.  Management-free Shortest Path Based Protection

258        An alternative protection strategy consists in management-free local
259        protection, aiming at providing a repair for the destination based on
260        the shortest path to the destination.

262        In our example, C protects Z, that it initially reaches via CD, by
263        enforcing the traffic over its shortest path to Z, considering the
264        failure of the protected component.  The resulting end-to-end path
265        between A and Z, upon recovery against the failure of CD, is depicted
266        in Figure 3.

268                              B * * *C------D------E
269                              *|      | *  / | \  / |\
270                            * |      |  */  |  \/  | \
271                            A  |      |  /*  |  /\  |  Z
272                            \ |      | /  * | /  \ | *
273                              \|      |/    *|/    \|*
274                              F------G------H * * *I

276                  Figure 3: Shortest path protection around link CD

278    4.  Managed Local Protection

280        There may be cases where a management free repair does not fit the
281        policy of the operator.  For example, in our illustration, the
282        operator may not want to have CD and CH used to protect each other
283        due the BW availability in each link and that could not suffice to
284        absorb the other link traffic.

286        In this context, the protection mechanism MUST support the explicit
287        configuration of the backup path either under the form of high-level
288        constraints (end at the next-hop, end at the next-next-hop, minimize
289        this metric, avoid this SRLG...) or under the form of an explicit
290        path.

292        We discuss such aspects for both bypass and shortest path based
293        protection schemes.

295    4.1.  Managed Bypass Protection

297        Let us illustrate the case using our reference example.  For the
298        demand from A to Z, the operator does not want to use the shortest
299        failover path to the nexthop, {CH, HD}, but rather the path {CG, GH,
300        HD}, as illustrated in Figure 4.

302                              B * * *C------D * * *E
303                              *|      * \  / * \  / |*
304                            * |      *  \/  *  \/  | *
305                            A  |      *  /\  *  /\  |  Z
306                            \ |      * /  \ * /  \ | /
307                              \|      */    \*/    \|/
308                              F------G * * *H------I

310                        Figure 4: Managed Bypass Protection

312        The computation of the repair path SHOULD be possible in an automated
313        fashion as well as statically expressed in the point of local repair.

315    4.2.  Managed Shortest Path Protection

317        In the case of shortest path protection, the operator does not want
318        to use the shortest failover via link CH, but rather reach H via {CG,
319        GH}, for example, due to delay, BW, SRLG or other constraint.

321        The resulting end-to-end path upon activation of the protection is
322        illustrated in Figure 5.

324                              B * * *C------D------E
325                              *|      * \  / | \  / |\
326                            * |      *  \/  |  \/  | \
327                            A  |      *  /\  |  /\  |  Z
328                            \ |      * /  \ | /  \ | *
329                              \|      */    \|/    \|*
330                              F------G * * *H * * *I

332                    Figure 5: Managed Shortest Path Protection

334        The computation of the repair path SHOULD be possible in an automated
335        fashion as well as statically expressed in the point of local repair.

337        The computation of the repair path based on a specific constraint
338        SHOULD be possible on a per-destination prefix base.

340    5.  Loop Avoidance

342        It is part of routing protocols behavior to have what are called
343        "transient routing inconsistencies".  This is due to the routing
344        convergence that happens in each node at different times and during a
345        different lapse of time.

347        These inconsistencies may cause routing loops that last the time that
348        it takes for the node impacted by a network event to converge.  These
349        loops are called "microloops".

351        Usually, in a normal routing protocol operations, microloops do not
352        last long enough and in general they are noticed during the time it
353        takes for the network to converge.  However, with the emerging of
354        fast-convergence and fast-reroute technologies, microloops may be an
355        issue in networks where sub-50 millisecond convergence/reroute is
356        required.  Therefore, the microloop problem needs to be addressed.

358        A set of technologies preventing and addressing microloops have been
359        proposed (e.g.: [I-D.ietf-rtgwg-uloop-delay]).

This reference is to a solution – and it otherwise just seems out of place.


361        Networks may be affected by microloops during convergence depending
362        of their topologies.  Detecting microloops can be done during
363        topology computation (e.g.: SPF computation) and therefore
364        microloops-avoidance techniques may be applied.  An example of such
365        technique is to compute microloop-free path that would be used during
366        network convergence.

368        The SPRING architecture SHOULD provide solutions to prevent the
369        occurrence of microloops during convergence following a change in the
370        network state.  Traditionally, the lack of packet steering capability
371        made difficult to apply efficient solutions to microloops.  A SPRING
372        enabled router could take advantage of the increased packet steering
373        capabilities offered by SPRING in order to steer packets in a way
374      that packets do not enter such loops.

376    6.  Co-existence of multiple resilience techniques in the same
377        infrastructure

379        The operator may want to support several very different services on
380        the same packet-switching infrastructure.  As a result, the SPRING
381        architecture SHOULD allow for the co-existence of the different use
382        cases listed in this document, in the same network.

384        Let us illustrate this with the following example:

386        o  Flow F1 is supported over path {C, CD, E}

388        o  Flow F2 is supported over path {C, CD, I}

390        o  Flow F3 is supported over path {C, CD, Z}

392        o  Flow F4 is supported over path {C, CD, Z}

394        It should be possible for the operator to configure the network to
395        achieve path protection for F1, management free shortest path local
396        protection for F2, managed protection over path {CG, GH, Z} for F3,
397        and management free bypass protection for F4.

399    7.  Security Considerations

401        This document describes requirements for the SPRING architecture to
402        provide resiliency in SPRING networks.  As such it does not introduce
403        any new security considerations compared to the ones related to the
404        SPRING architecture defined in [RFC7855] and
405        [I-D.ietf-spring-segment-routing].

s//…any new security considerations beyond that is discussed in [RFC7855].


Take out the reference to the architecture.



407    8.  IANA Considerations

409        This document does not request any IANA allocations.

411    9.  Manageability Considerations

413        This document provides use cases.  Solutions aimed at supporting
414        these use cases should provide the necessary mechanisms in order to
415        allow for manageability as described in [RFC7855] and
416        [I-D.ietf-spring-segment-routing].

Take out the reference to the architecture.


418        Manageability concerns the computation, installation and
419        troubleshooting of the repair path.  Also, necessary mechanisms
420        SHOULD be provided in order for the operator to control when a repair
421        path is computed, how it has been computed and if it's installed and
422        used.

424    10.  Contributors

426      Pierre Francois contributed to the writing of the first version of
427        this document.

429    11.  Acknowledgements

431        Authors would like to thank Stephane Litkowski and Alexander
432        Vainshtein for the comments and review of this document.

434    12.  References

436    12.1.  Normative References

438        [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
439                  Requirement Levels", BCP 14, RFC 2119,
440                  DOI 10.17487/RFC2119, March 1997,
441                  .

443        [RFC7855]  Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
444                  Litkowski, S., Horneffer, M., and R. Shakir, "Source
445                  Packet Routing in Networking (SPRING) Problem Statement
446                  and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
447                  2016, .

449    12.2.  Informative References

451        [I-D.ietf-rtgwg-uloop-delay]
452                  Litkowski, S., Decraene, B., Filsfils, C., and P.
453                  Francois, "Microloop prevention by introducing a local
454                  convergence delay", draft-ietf-rtgwg-uloop-delay-02 (work
455                  in progress), June 2016.

457        [I-D.ietf-spring-segment-routing]
458                  Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
459                  and R. Shakir, "Segment Routing Architecture", draft-ietf-
460                  spring-segment-routing-09 (work in progress), July 2016.

462    Authors' Addresses

464        Clarence Filsfils (editor)
465        Cisco Systems, Inc.
466        Brussels
467        BE

469        Email: cfilsfil@cisco.com
470        Stefano Previdi (editor)
471        Cisco Systems, Inc.
472        Via Del Serafico, 200
473        Rome  00142
474        Italy

476        Email: sprevidi@cisco.com

478        Bruno Decraene
479        Orange
480        FR

482        Email: bruno.decraene@orange.com

484        Rob Shakir
485        Google, Inc.
486        1600 Amphitheatre Parkway
487        Mountain View, CA  94043

489        Email: robjs@google.com

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The Intended Status is 'Informational'. 
  The type of RFC is properly indicated in the title page header.
  This draft provides information on use cases and requirements for solution. Informational RFC looks the best option.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The document provides various use cases to use SPRING to enhance network resiliency.
It provides requirements for solutions but does not detail those solutions which is inline with the document goal.
Separate documents are required to detail the solutions.


Working Group Summary

This draft has been discussed in the WG, with WG comments included in the revision of the draft.
Most of discussions were around the path protection use case text. All comments have been correctly addressed by
the authors leading to a better text that have consensus.


Document Quality

This document is an old document, and some use cases described already have implementations today :
for example, the management free local protection.
The use case "managed shortest path protection" does not seem to have any implementation plan.


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?
  Stephane Litkowski is the Document Shepherd.
  Alvaro Retana is the responsible Area Director.
 

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


The draft has been thoroughly reviewed by the Shepherd, leading to a set of comments sent to the authors.
The comments were all addressed in the last document revision and
the document is now ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

N/A


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors have stated not been aware of undisclosed IPR which would apply to the Document.



(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosed for this document.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The draft explains use cases and requirements that are well understood
and agreed by the WG after some discussion.
We have now a solid consensus on the content of the document
within the working group.



(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There is no area of conflicts about this document.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No ID nits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document is a requirement and use case presentation document that
does not require additional formal review.

(13) Have all references within this document been identified as
either normative or informative?

All references are correctly identified.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are existing RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There is no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The state of other documents remains unchanged.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This draft has no action for IANA.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A