IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-02-04. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
Telechat:
3.4.2 Returning items
1025 EST no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
Telechat::
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1057 EST Entered Executive Session
(at 2016-02-04 06:00:06 PST)
draft-ietf-tsvwg-sctp-failover
Thanks for a clearly written specification. - Should this formally UPDATE 4960? I don't care but some might:-) If you want new SCTP implementations to include this then adding the UPDATES may make sense. - 3.2, step 9: Just wondering: is this still true even if the implementation knows that the ack was received from a destination address that is currently in the PF state? (Say if all destination addresses are on different interfaces, and I can see on which interface I rx'd the ack, and that maps 1:1 with a destination address in the PF state.)
- 3.2: Since PMR is allowed to be greater than zero, there is the potential to have a non-zero error count but not yet have entered the potentially failed state. Did I miss guidance on when the error count might be reset under those conditions? (I found guidance for when in the potentially failed state.) -3.2, 4: The paragraph says the sender MUST follow the following rules, but both of those rules just say SHOULD. I'm not sure what that means. - 3.2, 7: "sender SHOULD clear the error counter" Why not MUST? - 4, 3rd paragraph: "handling SHOULD NOT be coupled" Why not MUST? - 6: The recommended value for PFMR is redundant with an earlier section. Editorial: - There are a number of places where paragraphs are put into long numbered lists for no apparent reason. Could those not just be normal paragraphs? As it is, I keep getting section numbers and paragraph numbers confused. - 3.2, 3.ii:"...the sender thus by [RFC4960], section 6.4.1, should attempt..." The wording is confusion. I think you mean something to the effect of "According to [RFC4960] section 6.4.1, when the sender retransmits data that has timed out, it should attempt..." - 3.2, 4, last paragraph: The current wording can be interpreted ambiguously. I think you mean the following: OLD The sender MUST NOT change the state and the error counter of any destination address regardless of whether it has been chosen for transmission or not. NEW The sender MUST NOT change the state and the error counter of any destination address simply because it has been chosen for transmission. END - 6: RECOMMENDATIONS should not be capitalized. -7: The section says it's informational. Does that include child sections? I found at least one 2119 MAY at te end of 7.2.
As discussed by Jürgen Schönwäder (part of this OPS DIR review) and the authors. Jürgen: Since the I-D introduces the new state Potentially Failed, does this imply that an update of the SCTP-MIB [RFC3873] (sctpAssocState) is needed as well? Are there additional MIB objects to report, e.g., spt_pathpfthld and spt_pathcpthld? I see some additional SCTP related docs in TSVWG and perhaps after they have been completed an update of the SCTP-MIB would make sense to consider. Yoshifumi Nishida: I think it makes senses to update MIB. We'll check with implementors and other experts. Thanks for pointing it out. Ideally, you should add a sentence or two expressing that RFC3873 should be updated to support this functionality with a few objects that ...
In addition to the 2119 issues that Ben has raised...
In Section 3.2 bullet 1:
The RECOMMENDED value of PFMR is
0, but other values MAY be used.
"SHOULD do X, but MAY do Y" makes no sense. In this case, you can (should)
just remove "but other values MAY be used". You might instead say *why* 0 is
recommended at a 2119 level (implying that it has interoperability
implications).
In bullet 9, I found this to be oddly worded:
A SCTP sender MAY clear the error counter
and move a destination address back to active state if it has
other information, than the acknowledgment, that uniquely
determines which destination, among multiple destination
addresses, the chunk reached.
Perhaps this?:
NEW
A SCTP sender MAY clear the error counter
and move a destination address back to active state if it has
information other than the acknowledgment that uniquely
determines which destination, among multiple destination
addresses, the chunk reached.
END
Juergen Schoenwaelder performed the opsdir review
draft-ietf-ntp-extension-field
If you do revisit the MACing setup, (as indicated in the response to the secdir review [1]), I hope you maybe consider taking some input on this from security folk - having a scheme where essentially random parts of the packet are/are-not protected by a MAC isn't necessarily a good way to go. I do totally agree that getting away from depending on the length to figure out the algorithm is a thing that definitely should be done, and moving to use modern ciphers as well of course;-) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06329.html
Thank you for writing this much clarifying document! I want to recommend its approval with a 'Yes' position, but before that I had one question which I believe would benefit from some discussion: Section 7.5.1.2 says: If an NTP packet is received with two or more extension fields that require a MAC with different algorithms, the packet MUST be discarded. However, Section 7.5 already said earlier: If a host receives an extension field with an unknown Field Type, the host SHOULD ignore the extension field and MAY drop the packet altogether if policy requires it. This leaves me wondering how the MUST-drop-packet-with-fields-with-different-algs can be implemented. Did you perhaps mean: If an NTP packet is received with two or more extension fields that this receiver recognises and those fields require a MAC with different algorithms, the packet MUST be discarded. Or maybe something else? Can you clarify?
tim chown provided the opsdir review
draft-ietf-ecrit-held-routing
Nit: "funciton" should be "function". In this text: Evolving architectures in Europe to address regulatory requirements, such as [M493], couple location and routing information in the access network whilst using a softswitch-centric approach to emergency call processing. "softswitch-centric" is clearly defined in Section 3, but that's later in the document. Perhaps you could include a forward reference to Section 3 here?
section 4: The optional service URN seems like a thing where it could be dangerous to be over-general, and where being specific to emergency calling services would be a good restriction. I would not like "service=urn:advertising" to be something that'd work here. (At least not without consideration of how that could be used for ad blocking:-) The registry from RFC5031 does however seem to control that correctly (via standards action or ECRIT WG/IESG review) so I think it'd be better here to say that the service URN MUST be in that specific registry. If that is already in the text that's fine, but I didn't read it as quite having that MUST.
There is some confusion about whether this draft updates 6881. The headers and section 5 say it does, but the abstract does not. (Since the abstract _does_ mention 5985, I assume the authors intended to follow the convention of mentioning such things in the abstract.) It would be nice to have a sentence or two on why some countries are reluctant to deploy public LoST servers. (I recognize there may be too many worms in that can, so feel free to ignore.) - section 5, 2nd paragraph: I don't understand the 2nd sentence. It seems like this updates 6881 or it doesn't.
Jouni Korhonen's Gen-ART review raised some comments that are worth looking at.
A detail but since I spent time writing it while performing my review, here it
is.
Sure, I should know about all the references before reading this document, but
simply things such as expanding the first acronym occurences facilitates the
reading.
Public Safety Answering Point (PSAP)
Location-to-Service Translation (LoST)
Ah. Now, I arrive to section 2, where I see those...
I note that the reference to 5687 was moved to informative in -04. I think the fact that it's used as the reference for privacy and security considerations leads to its being normative, as it originally was. But, really, I think the right fix for that is to change the phrases in Sections 8 and 9 that say "beyond those already described in [RFC5687]" to instead say "beyond those already described in [RFC5985]". I think using the security aspects of the base HELD protocol as the basic considerations for this extension is the right thing. Comments?
The following is a training review from Suresh Krishnan (incoming INT AD) * Section 7 Not using documentation address block for examples. Using RFC1918 space instead. IANA has allocated 192.0.2.0/24 for documentation use.
ip address examples are no more meaningful/less if documentation prefixes are used...
draft-ietf-isis-te-metric-extensions
I was a contributor
- Couldn't exposing these metrics (e.g. to a passive attacker) help the attacker decide which part(s) of a network to attack or help the attacke to measure the effectiveness of some other attack they have mounted? (E.g. a physical attack on fibre) I think that is worth noting in section 11, perhaps with guidance that sending this information in clear over less trusted parts of the network might best be avoided, e.g. by encrypting that traffic? Put another way... I agree with Alissa's 2nd discuss point, but I'd argue that the proposed re-phrasing (from mail from Stefano on Feb 2nd) ought include the above and not only say "might be sensitive." - Would it be worth noting that if a future specification allows some control node or router to ask another to emit these metrics, then that future specification will need to consider (abuse of) that control interface as a new attack vector?
I concur with Alissa's 2nd discuss point. -11, paragraph 4: s/"dame operator"/"same operator"
From Nevil Brownlee (OPS DIR reviewer) and Stefano Previdi's discussion: > I have one issue to raise: the last paragraph of section 2 > (introducing the metrics to for each of the new sub-TLVs) says that > the values "MUST be calculated as rolling averages where the averaging > period MUST be a configurable period of time." This draft does not > say how that interval will be configured. the paragraph refers to section 5 “Announcement Thresholds and Filters” where the thresholds and average values are explained. The specifics of the configuration are not present because these are implementation specifics aspects. The same has been done in RFC7471 which is the OSPF version of this draft. > For proper operation, > surely all participating IS-IS routers will need to use the same > measurement interval? Well, while it would make sense to use the same interval, it is not a requirement and it’s possible to have a network where nodes use different intervals to measure their links utilization. Also, as described in section 5, the interval may vary and advertisements may be done immediately in some cases. > I suggest that some text explaining this, and > saying how a router's measurement interval can be checked by other > routers, would be useful. Here also there are no requirements for a router to be able to verify which interval other routers used. ===================================== Since that triggered some questions/discussions, a few sentences around the following points would make sense from an OPS point of view: - While it would make sense to use the same interval, it is not a requirement and it’s possible to have a network where nodes use different intervals to measure their links utilization - There are no requirements for a router to be able to verify which interval other routers used. Regards, Benoit
I've only a couple of minor comments to add to what my colleagues have already said: -- Section 1 -- For links, such as Forwarding Adjacencies, care must be taken With the first comma, the qualifier "such as Forwarding Adjacencies" is only parenthetical. I think you're *specifically* talking about "links such as Forwarding Adjacencies" here, so you need to remove that comma. -- Section 5 -- Min and max delay MAY be the lowest and/or highest measured value over a measurement interval or MAY make use of a filter, or other technique, to obtain a reasonable representation of a min and max value representative of the interval with compensation for outliers. Making sure this normatively says what you want it to: What this says is that min and max delay can be anything anyone wants it to be, with no restrictions at all, because there are only 2119 "MAY" key words here, and "MAY" means optional. Specifically, it means that min and max do NOT have to have any resemblance to any reasonable representations. What I think you *mean* to say is that they each MUST be one of two things: either taken from measured values or be reasonable representations. You can freely choose between those, but they have to be one or the other. Is that correct? If that's correct, then you need to say it in some manner such as this: NEW Min and max delay MUST each be derived in one of the following ways: by taking the lowest and/or highest measured value over a measurement interval, or by makeins use of a filter or other technique to obtain a reasonable representation of a min and max value representative of the interval, with compensation for outliers. END
* The Introduction dismisses queuing delays. However, queue delays pose a large risk to minimizing path delay (and delay variation). How useful is a "minimal delay" path computed by IS-IS if queue delays are not accounted for? * Does this document use the same definition of delay variation as RFC 3393? There is no clear definition of delay variation provided in this document. * Section 4.3 states that the "delay variation advertised by this sub-TLV MUST be the delay from the local neighbor to the remote one." I would assume that "the delay from" is really meant to be "the variation in delay from". Secondly, how does the local (transmitting?) neighbor know the variation in delay? That is typically measured by the receiving neighbor.
(1) There seems to be some inconsistency in the way the A-bit is described as
applied to the min/max delay sub-TLV. Section 4.2 says:
"A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set
when the measured value of this parameter exceeds its configured
maximum threshold. The A bit is cleared when the measured value
falls below its configured reuse threshold. If the A-bit is clear,
the sub-TLV represents steady state link performance."
Is the A-bit meant to apply only to the min delay? Or only to the max delay?
Then Section 5 says:
"For sub-TLVs which include an A-bit (except min/max
delay), an additional threshold SHOULD be included
corresponding to the threshold for which the performance
is considered anomalous (and sub-TLVs with the A-bit are
sent)."
Since min/max delay is excepted from this recommendation, I don't understand
what the A-bit means in the min/max delay sub-TLV.
(2) Section 11 says:
"This document does not introduce security issues beyond those
discussed in [RFC5305]."
This seems false. First, RFC 5305 doesn't seem to discuss any security issues.
It points to RFC 5304. But even compared to RFC 5304, it seems this document
does introduce new issues, because it exposes real-time performance information
about the network which may be commercially sensitive, and which RFC 5305 does
not expose. So, for example, the claim in RFC 5304 that "Because a routing
protocol contains information that need not be kept secret, privacy is not a
requirement," does not seem true. It may be that the same authentication
mechanisms can be used, but that doesn't mean the threat model is the same.
Happy to defer to others with more routing security clue than I, but it seems
like at a minimum the potential value of the information contained in the new
sub-TLVs to an attacker needs to be acknowledged.
(1) In Section 5: OLD Min and max delay MAY be the lowest and/or highest measured value over a measurement interval NEW Min and max delay MAY be the lowest and highest measured value over a measurement interval, respectively, (2) Section 11 says: "It is anticipated that in most deployments, IS-IS protocol is used within an infrastructure entirely under control of the dame operator." But Section 1 says: "The data distributed by the IS-IS TE Metric Extensions proposed in this document is meant to be used as part of the operation of the routing protocol (e.g. by replacing cost with latency or considering bandwidth as well as cost), by enhancing Constrained-SPF (CSPF), or for other uses such as supplementing the data used by an ALTO server [RFC7285]." In the ALTO case at least it would seem like the point of using this data would be to inform applications (outside the control of the operator) about the cost of routing traffic a certain way. I think this section could be more clear about the expectation that the performance data it exposes may be factored into such costs that get published outside the operator network.
Nevil Brownlee perfromed the opsdir review
draft-ietf-rtgwg-mrt-frr-architecture
- abstract: "IP/LDP" is a bit ambiguous - it could be read as "IP over LDP," "IP and LDP" or "IP or LDP" not all of which make sense I guess:-) Be better if the abstract said "IP and LDP" I think. - section 3: the definitions are very dense - would re-ordering them help maybe? Not sure myself, but maybe think about it. - Section 8: with so many parameters, why choose an 8-bit profile ID? That seems to be a bit short-sighted maybe? - 12.2: The sequence presented here has the look of something that might be a potential DoS vector, but maybe the computation isn't that significant, not sure. Did you consider a potential attack where the bad actor takes down then re-instates one or more links so as to increase the computation to the max? (Perhaps you did and the max is still not a big deal.) - As noted by the secdir review [1] this is highly acronym laden. I'd encourage an editing pass to try reduce that where possible. I'll also bet a beer that not every acronym used is either expanded or else present in the list of "well known" acronyms (which is of course pretty outdated). [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06344.html
We're lucky to have two OPS DIR reviews for this document. From Fred Baker: In my view, although I have concerns as I am about to state, I consider the draft to be ready for IESG review and potential publication as an RFC at Proposed Standard. I have no specific issues I would like to see addressed, nor do I believe the technology or draft to be fundamentally flawed. Speaking in general terms, this draft describes a solution for the problem posed in RFC 5714, which is to say a solution for fast reroute in a network whose routing is implemented using IS-IS and LDP. It is not the only possible solution. In terms of graph theory, we might define a "connected graph" as a set of "nodes" and a set of "links" that interconnect them, such that every node is connected via some sequence of links and nodes to each of the other nodes in the connected graph. The Maximally Redundant Tree model seeks to divide the connected graph into two or more connected sub-graphs, each of which connects the same set of nodes, but using sets of interconnecting links whose intersection set is null, or is at least minimized. In the event that a link in one connected sub-graph fails, the network can continue to use another connected sub-graph to guide routing during the outage. There are obvious degenerate cases, in which the sets of links in sub-graphs are forced to overlap to some degree, or some nodes are not found in all sub-graphs. Part of the architecture is designed to identify those cases (which might occur, for example, in the presence of multiple simultaneous failures, or when the network is inherently deficient for reasons unrelated to and perhaps in violation of the mathematics) and handle them as best it can. As one might imagine, this is not trivial. My first comment on reading the architecture (and on reading the algorithm, which is a separate document) is that the algorithm is complex, and therefore (like anything that is complex) prone to errors and failures of various kinds, and potentially has failure modes that have not yet been detected. This is not to be considered as a strike against it, but a point of caution; the operator using the approach wants to ensure that s/he has the tools necessary to monitor network health, and to quickly discover and correct errors if and when they occur. The algorithm draft contains several proofs of correctness for various parts or in various cases, and refers to papers containing such proofs, with the intent of minimizing the inherent risk. That said, to my knowledge there is not a global proof of correctness, as there is for example in the Shortest Path First algorithm or other algorithms used in the network. The risk is therefore not zero. From the perspective of the IETF, that is precisely the reason a protocol like this should be used operationally at the Proposed Standard level, updated as needed, and ultimately re-released as an Internet Standard when the algorithm and implementations have been operationally proven. With that introduction, the first question in my mind is whether the description is such that two implementors are likely to be able to implement interoperable implementations, or whether ambiguities or lack of clarity would prevent that. This draft identifies two proprietary prototype implementations, by Huawei and Juniper, which if they are interoperable would address the question to a considerable degree. The draft does not, however, describe interoperability testing between them, which at least suggests that this might be yet future. On this score, given the complexity of the design, I personally would be greatly comforted by a test report along the lines of RFC 1246. Since such tests usually find text that needs tweaking, I might suggest that the publication at RFC be delayed until such testing can be performed and the lessons learned, whatever they are, incorporated in the documents. Failing that, experience leads me to believe that there will be subsequent documents that update or obsolete these. The corollary question in my mind is whether an operator reading the architecture will be able to figure out how to effectively use it. On this score, I give the draft a thumbs-up. It is well written, the various issues are raised and dealt with, and the ramifications are in my view clear. Now the review from Nevil Brownlee: This is a long draft, presenting the MRT-FRR architecture, and exploring in some detail the design alternatives that were possible during that process. There are many acronyms used throughout the draft, that will work well for routers familiar with Routing in general, and MPLS in particular. Others will find it useful to keep a browser window at hand! For me, PLR (Point of Local Repair) was new. In section 11.1, the equations that test whether a path is loop-free for nodes S and F use D_opt() as an abbreviation for Distance_opt() [RFC 5286] - I understand the authors wish to get these equations onto single lines, but the phrase "where D_opt() means Distance_opt()" would be helpful. Throughout the draft the phrase "protocol extensions to .. will be defined elsewhere" appears, similarly the IANA Considerations section defines an MPLS Multi-Topology Identifiers Registry, but says that codepoints in it will be defined elsewhere. Clearly this draft is the first in what will become a cluster of RFCs. On the Operations side of things, section 1.2 notes that "MRT-FRR supports partial deployment." That will allow Operators to deploy it in stages (one MRT Island at a time?). Further, several sections consider the possibility of "link-protecting alternates causing route looping," it seems that MRT-FRR should remain loop-free. Section 13, Implementation Status [to be removed by the RFC Editor], demonstrates that at least two implementations exist, clearly that has helped the authors to work through the design decisions I commented on above. Section 14, Operational Considerations, works through the most important of the decisions an Operator will need to make if they plan to implement MRT-FRR - this seems very useful. Overall, the draft is well-written and easy to read (apart from its high acronym density), I believe it is ready for publication as an RFC.
The IANA Considerations section creates a new registry for the MRT Profiles. It allocates "Values 221-255 are for vendor private use." Are there limitations/guidance on how vendors use this range? Should Section 8,14 or 17 say something about dealing with these ranges in operational networks?
Nevil Brownlee performed the opsdir review
draft-ietf-rtgwg-mrt-frr-algorithm
- That's an awful lot of code to have zero new security considerations associated with the spec. Go on - tell me: did you really consider if there were some or not? :-) - I don't think the secdir review [1] has yet gotten a response. Nothing major there, but good to reply if you've not already. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06335.html
draft-ietf-ippm-checksum-trailer
3.2.3, 2nd paragraph: "...OWAMP/TWAMP layer SHOULD treat the Checksum Complement as part of the Packet Padding." The previous paragraph said this put no new requirements on the receiver. Is the SHOULD here a new requirement, or a statement of fact? (If the latter, it should not use the 2119 keyword.)
This document lacks sufficient justification for why the checksum trailer is needed. I would suggest a brief description of when this approach is needed.
There seems to be a bit of a disconnect between this text in 3.2: "As specified in Section 3.4. , the Checksum Complement should only be used in unauthenticated mode." and this text in 3.4.1: "A Checksum Complement MAY be used when authentication is enabled. In this case an intermediate entity can timestamp test packets and update their Checksum Complement field without modifying the HMAC." I can see why not to use the checksum complement in encrypted mode, but don't see why it can't be used in authenticated mode for TWAMP.
Al morton did the ops dir review.
draft-ietf-spring-problem-statement
Thanks for putting in the effort in writing this. Firstly, I concur with Benoit's observation about text taken from the charter and laid in to the document verbatim. That tends not to help the reader and a large assumption is made that the reader understands the concerns of source based routing for partitioning VPNs, fast re-route, TE, signalling, and so on. Please consider rewriting the intro and other parts to help with understanding (for example in 3.2 Fast Reroute; microploop avoidance is listed as a requirement, however a sensible coverage of microloop avoidance is not found in the draft, nor in the nearby referenced spring-resiliency-use-cases). This also leaves me scratching my head as to why we don't see this document and the resiliency-use-cases (and others) at the same time when they are aligned? Or restructure the document to be more informative on these facets in the first case. Can the document also be explicit that while the SPRING problem/solution space needs to be cognisant of autonomous systems that share policy/interoperate across boundaries the primary port of call is in regard to the IGP. This will certainly aide in restraining everyone (esp. the reader) from trying to boil the 'internet ocean'. (this at least should be easy to address :)
The main focus of my discuss are the disparaging comments on MPLS and RSVP-TE for the apparent purpose of justifying the need for SPRING. The statements in Section 3.3, paragraph 2, are not accurate. As an IETF document, even though Informational, it harms another IETF technology. This paragraph needs to be removed. Very disappointing to see this unfair comparison of centralized control vs. distributed control in an IETF document.
As others commented, the document is missing the identification of key requirements, “MUST”. The Abstract’s last sentence and Section 3.1 say the objective is to address use cases where removal of signaling and path state in the core is a requirement. Yet, 3.1.1 and 3.2 only say it “SHOULD” work without the addition of a signaling protocol. If any requirement is a “MUST”, it would seem this requirement needs to be a “MUST”. There is no need to make statements that RSVP-TE is complex and not scalable to justify. Just say simply you do not want to use a distributed control plane for your problem. This is not the first time for this requirement. As for no need for state at transit nodes, it’s not quite true, as there probably is a need to map the SR “label” to a label stack instruction and a forwarding instruction. Hint, the “MUST” would be similar to MPLS-TP requirements [RFC5654], “SPRING MUST support the capability for network operation without the use of any control-plane protocols.” The interchangeability of the terms “SPRING” and “segment routing” are confusing. I think if you would clarify the control model, it may help with the definitions. Section 1: “allow optimal virtualization by putting policy state in the packet header” and “policy is completely virtualized away from midpoints and tail-ends” doesn’t parse. By definition, it’s not “virtual” if it’s in the packet header. Seems to be a marketing statement, not a technical requirement. Section 2: It seems the document is already defining the solution for IPv6 segment routing. It would help to say what is the actual requirement – packets should be forwarded transparently through a legacy v6 network? Identifiable by SPRING-capable devices? Section 3: These use cases appear to be defining desired capabilities for a controller, not SPRING. It would be helpful to clarify what are the requirements for the dataplane’s “simple support” e.g. section 3.2 on FRR appears to be requirements on the controller, not the dataplane. And 3.3.1.2.1 on a capacity planning process in the controller. Section 3.3 Traffic Engineering: While this is labelled Traffic Engineering, the examples are only on traffic placement. Only a subset of Traffic Engineering. The other key aspect of TE is resource reservation. The text should clarify and refer to traffic placement and not the general term “TE”. Section 3.3.1.1 are all load balancing examples – not “TE”. While valid and useful, should not confuse the reader that it is TE. Section 3.3.1.2.2 I don’t think everyone would agree that a stateful PCE is an SDN controller. I think there is some confusion, especially the next paragraph, on a controller vs. orchestrator. There’s a lot of marketing hype in this section, best would be to say something generic and what it is doing (technically) e.g. “centralized-based optimization” (next paragraph). The requirements in this section seem to be generic, not “SDN”. I don’t understand the last one, “no delay is introduced to programming the midpoints and tail-end along the path”. Compared to what? If a change, is there a change for traffic placement within the network? Before a change, there also is delay - the controller usually will sync with the current state of the network. This sounds marketing “highly responsive to change”. State the requirement for SPRING. Missing requirements: OAM, any requirements on limiting the increased headers and overall frame size?
I'm not going to block over this, but I share the question about why this should be published as an RFC. It seems to be intended to guide other work. Once that work is done, will people still need this? This might be more appropriate for a wg wiki. The "Requirements Language" section contains the standard RFC 2119 boilerplate. But this draft does not use the terms as defined in 2119. That talks about implementation requirements, not requirements on new IETF work. If you want to keep the 2119 keywords, please adjust the boilerplate to say what you are actually doing. (Personally, I don't think the 2119 keywords add much, and may cause confusion. (Along those lines, I share Alissa's question about the heavy use of SHOULDs). The security considerations are inadequate. I would like to see more about the potential threats for a source-routed system. For example, is it a privacy issue if you leak routes across a domain boundary? Could an attacker modify routes to cause traffic to be routed to a tap point? (etc) Several of the informative references define use cases that seem to be necessary to fully understand this document. Please consider making them normative.
I would like to discuss this point with the responsible area director during the telechat. No action from the authors is required on this point at this point. The manageability considerations section is a direct cut/paste from a charter (i.e. minimal effort) + two informative references to drafts, not even WG docs. What are we suppose to conclude from this, in terms of manageability requirements?
- It seems to me that, when speaking of SPRING, people speaks of Segment Routing. The section title 3.3.1.2.2. is "SDN/SR use-case" btw. Why not mention it somewhere in the doc, for this first SPRING document? "SPRING is also known as Segment Routing" - The SPRING architecture SHOULD support traffic engineering, including: To be consistent with the two previous use cases, I guess you want: The SPRING architecture SHOULD support the following traffic engineering, requirements: Otherwise, it seems that TE is an optional use case, which somehow contradicts: In this context, Source Packet Routing in Networking (SPRING) architecture is being defined in order to address the use cases and requirements described in this document. =============================================================== Now updated with Tim Chown's OPS DIR review: Overall this document is quite close to being ready, but I have a few comments below for consideration by the AD / authors. This draft is a problem statement (in the form of a number of use cases) and a set of requirements for Source Packet Routing in Networks (SPRING) or, as it is otherwise known, Segment Routing. It is one of a large number of active documents in the SPRING WG, as listed at https://tools.ietf.org/wg/spring/. These include forays into solution space (e.g. the IPv6 SRH, tagged as a 6man draft) and the SPRING architecture, which can be found at https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07. There is clearly significant interest in the IETF in developing the SR architecture(s) and solutions. The work in SPRING is already quite advanced, and thus one might query the value of extensive effort in nailing down the problem statement and requirements. However, I feel it is proper that the WG should ensure that the basis for their published solutions has been through an appropriate consensus process, esp. should the rationale for certain requirements need to be revisited in the future. In that light, the document feels somewhat ??note form??, in that requirements are scattered through the discussed use cases, and many are not explained in any detail (presumably as the authors assume certain level knowledge from those in the WG), e.g. what is meant by ??shared risk constraints?? ? The terminology could be better explained, for a broader audience, and to reduce any potential ambiguity. The requirements take the form of (depending on how you count them) 32 SHOULDs, and there are, perhaps a little surprisingly, no MUSTs. Are the authors confident that every SHOULD is just that, and that there are no mandatory requirements? I might have queries over certain capabilities (implementations of requirements) in the document, e.g. insertion / removal of IPv6 SRHs, but I think it's better that this document avoids drifting into discussing potential solution spaces. The Security Considerations section is quite light, though it does contain one SHOULD. I assume more detailed security discussion is to be contained in the solution documents, although I note that the Security Considerations section of the architecture document is also very brief.
I agree with Alia's comment, "This draft doesn't feel as if it will be a useful RFC in 2 years." I think this is an example of a document that should be kept within the working group and used to guide its progress, but that doesn't seem to be a good candidate for going into the RFC archival series. I don't think my view on this should get in the way of publication, and so my "abstain" position.
A terminology section and describing at all the bullets of desired functionality would improve the readability. This draft doesn't feel as if it will be a useful RFC in 2 years.
The following is a training review from the Suresh Krishnan (incoming INT AD)
* Section 3.4
If the intent is to create a new RH type how will the interoperability or
backward compatibility be possible? Specifically because intermediate nodes
(that are segment routing hops) that encounter unknown RH types are required to
drop the packet and send an ICMPv6 Parameter Problem back.
* Security considerations
In general this document does not talk anything about the security issues with
IPv6 routing headers and how they would be avoided. e.g. The following paper
describes an attack.
[CanSecWest07] Biondi, P. and A. Ebalard, "IPv6 Routing Header
Security", CanSecWest Security Conference 2007,
April 2007.
http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
I think the security considerations are very light and need to be greatly
improved.
* Section 2 This section talks about the Routing header defined in RFC2460 but does not mention that the RH0 has been deprecated by RFC5095. Potentially worth mentioning draft-ietf-6man-segment-routing-header-00.
(1) I'm surprised that almost all of the requirements in this document are SHOULDs, since they mostly apply to an architecture and not individual solutions. In general I think it would help to explain the exception cases or the rationale for uncertainty about what the architecture will or won't support. (2) The security considerations section here appears to borrow text from the SPRING WG charter, but then is actually less specific than the charter about the anticipated mitigations that the SPRING architecture will provide against known threats. Given the structure of this document I would have expected detailed security requirements that any SPRING solution will be required to meet.
I find myself rather unsatisfied by The SPRING architecture SHOULD leverage the existing MPLS dataplane without any modification and leverage IPv6 dataplane with a new IPv6 Routing Header Type (IPv6 Routing Header is defined in [RFC2460]). in that the prospects for use of a new routing header, and ipv6 router/extension header treatment seem poor. and the potential consequences for chaining these for example seem worth exploring before electing that course of action.
draft-mahesh-mef-urn
Just nits, feel free to ignore or not: - Using https URLs is better than http, please consider doing that for the MEF site. That works just as well for me as the cleartext one. (Which is not that well at all, as both seem to need JS:-) - Same as the above for the IANA URL, if that's kept. - Please expand MEF properly somewhere.
I gather that "MEF" is no longer used as an acronym, but wondering if the organization really calls itself the "MEF Forum." In a quick search of public materials it seems to just call itself "the MEF."
conflict-review-dolmatov-kuznyechik
Please note that there has been discussion of this on CFRG. [1] That has not changed my position on this conflict review but we might want to chat briefly (or more) about it on the call. S. [1] https://mailarchive.ietf.org/arch/search/?email_list=cfrg&gbt=1&index=d63gZied3kHuytVHLtEkGSIBKfA