Subject: Re: [spring] WGLC for draft-ietf-spring-problem-statement

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 7 Oct 2014 15:22:14 +0000

On 9/23/14 2:28 PM, "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>> wrote:

[WG Chair Hat Off]

Hi!

As agreed at the last in person meeting, this message starts the Working Group Last Call for draft-ietf-spring-problem-statement.  This call will close by EOD (pick your favorite time zone) on October 8, 2014.

http://tools.ietf.org/html/draft-ietf-spring-problem-statement

Please provide specific feedback as to why you support (or not) the advancement of this draft.  Please avoid "+1"-type responses.

I support the publication of this document because I believe it provides a good general description of the use cases to be addressed.

I will be the shepherd for this document, so I have some comments that I would like addressed before we ask for publication.  I don't think any of my comments (see below) are show stoppers.

Thanks!

Alvaro.

Major:

  1.  Introduction.  The text says that "'source' means 'the point at which the explicit route is imposed'".  It would be really nice if the word "source" was used throughout the document in the same manner..for consistency, ease of searching, to reduce confusion, etc.   For example, in the Security section a short discussion was written to say: "There is an assumed trust model such that any node imposing an explicit route on a packet is assumed to be allowed to do so."..but the word "source" is not used.     Another example, section 5.1.1.2. (Egress Peering Traffic Engineering) reads: "The SPRING architecture should allow an ingress node (or a source node) to select the exit point of a packet.."  Is there a difference between an "ingress node" and a "source node"?  Would the source node (as the one imposing the explicit route) not be the ingress node?  I guess the only difference is whether the ingress node is a "source" as defined above or not.
  2.  Given that the document is defining requirements, shouldn't RFC2119 keywords be used (in some places at least)?  I see several "should" and some "must" used in the text, but none of them seem to be RFC2119 keywords.  If you think that no RFC2119 keywords should be used (which I think would not make it easier to determine whether the important requirements are satisfied or not), then please take the reference out.
  3.  References to the architecture documents should be removed..these are "forward" references as they point to work that should be done in response to the use cases defined in this document.  References that should be removed are: I-D.filsfils-spring-segment-routing-mpls, I-D.filsfils-spring-segment-routing, I-D.filsfils-spring-segment-routing-use-cases, I-D.filsfils-spring-segment-routing-ldp-interop..

Minor:

  1.  Introduction.  The last paragraph reads "SPRING architecture objective is not to replace.."  I think that this document's objective is to determine what the use cases are..not to determine the objective of the architecture.   If you want to rephrase as a requirement, please do.  Otherwise please remove it.
  2.  Dataplanes.  I like the first paragraph.  I think the rest of this section should talk about which dataplanes are in scope..and maybe about how the use cases described are not dataplane specific..  But not about whether MPLS or IPv6 can support what the use cases describe or not.  A nice requirement for this section might be something along the lines of "The SPRING architecture should leverage existing dataplanes without any modification, if possible." or "..with minimum modifications." (and not try to be prescriptive as to how the problem should be solved).  If you follow this suggestion, then the references to RFC2460, RFC6564 and RFC7045 are unnecessary.
  3.  Use Cases Section.  There isn't one. :-(  I think that the document would benefit from creating a section that includes the current sections describing use cases as sub-sections.  Or the other option would be to provide a "map" in the introduction so that the reader understands what each section contains.
  4.  Section 4. "FRR technologies.."  We need a reference here..specially since one of the requirements is to support FRR.
  5.  Section 5.  There's a lot of terminology in this section, but no references.  For example, "loose or strict options"..I'm sure there's a good reference where the reader can clearly find definitions.  IOW, please don't leave things up to interpretation.
  6.  5.1.2.2. (SDN/SR use-case)  There are several references in this section to potential pieces of an end-to-end solution that would incorporate a controller and SR: PCE, BGP-LS, i2rs, etc.  I think that those pieces of the e2e implementation of a system are outside the scope of this use cases document.  Similar to the suggestion for the Dataplanes section, mentioning that existing mechanisms be used as needed to complete the system should be enough.
  7.  5.1.2.2.1. (SDN Example)  This section seems to explain the result of what looks like the experiment of applying a potential solution to a full mesh.  The text in 5.1.2.2 should be enough.
  8.  Section 6 (Interoperability with non-SPRING nodes).  The only requirement in this section is the first sentence/paragraph.  The rest of the section is superfluous.  Do you have other requirements as to what it means to "interoperate"?   It would be nice to clarify whether the intent is to have support for "islands" of SR and islands of something else interconnected..or if the intent is to have SR and another technology work side-by-side in the same network.  I would assume the former..  [Note that there was a suggestion on the list to mention interoperability with OpenFlow.  Maybe that is too specific, which is why we need some clarity of what is expected..at least in this document.]
  9.  7. (OAM)  I think this section needs to be converted to the 'Manageability Considerations' section.  Pointing there to the work in progress should be ok.  BTW, the text reads: "The SPRING WG should provide OAM and the management needed to manage SPRING enabled networks.".  I'm assuming that you really meant the SPRING architecture.
  10. 8. (Security)  This should become the 'Security Considerations' section.
  11. "Authors' Addresses"  You still have 6 authors..the RFC Editor likes no more than 5.

Nits:

  1.  Introduction. s/In the context of this charter/In the context of this document
  2.  (In several places)  s/SPRING architecture/The SPRING architecture   The same for "MPLS Dataplane" or "IPv6 specification".
  3.  Section 3.  The two paragraphs are almost exactly the same.
  4.  Please review the acronyms and make sure they are expanded somewhere.
  5.  Section 3.1.  Where did 192.168.0.2 come from?  You later mention it..maybe you just need a generic explanation (as the rest of the use case).
  6.  Section 4. s/should address following/should address the following
  7.  5.1.1.1.  The description naming doesn't correspond to the figure: the description uses the notation C(1,k), while the drawing shows C1Z (for k = Z, of course).  It can be followed, but it would be better if it was straight forward.
  8.  5.1.1.1. "A should be able to.."    Which "A"?  The edge router, the region or maybe one of the other nodes..?
  9.  5.1.1.2.  There's a mention of "add-path", but no reference.
  10. 5.1.1.2. s/apply the following traffic-engineering policy/apply a traffic-engineering policy such as the following
  11. 5.1.1.3. s/allow a given node should be able to load share/allow a given node to load share
  12. 5.1.1.3. s/even if these ones lead/even if these lead
  13. 5.1.2.2. "..here are the benefits that the SPRING architecture should deliver.."  The architecture should deliver functionality. ;-)  Please reword appropriately.
  14. 5.1.2.2.1 s/ATM-alike/ATM-like
  15. 9. (IANA Considerations)  Write this: "This document has no IANA actions."