Source Packet Routing in Networking
charter-ietf-spring-02
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2023-03-29
|
02 | Amy Vezza | Responsible AD changed to Jim Guichard from Andrew Alston |
2022-03-23
|
02 | Amy Vezza | Responsible AD changed to Andrew Alston from Martin Vigoureux |
2018-10-02
|
02 | Cindy Morgan | New version available: charter-ietf-spring-02.txt |
2018-10-02
|
01-04 | Cindy Morgan | State changed to Approved from External review |
2018-10-02
|
01-04 | Cindy Morgan | IESG has approved the charter |
2018-10-02
|
01-04 | Cindy Morgan | Closed "Approve" ballot |
2018-10-02
|
01-04 | Cindy Morgan | WG action text was changed |
2018-10-02
|
01-04 | Cindy Morgan | New version to move milestones out of the charter text and into the milestone fields. |
2018-10-02
|
01-04 | Cindy Morgan | New version available: charter-ietf-spring-01-04.txt |
2018-10-02
|
01-03 | Cindy Morgan | Added charter milestone "Stateless service chaining with SR sent to IESG", due December 2019 |
2018-10-02
|
01-03 | Cindy Morgan | Added charter milestone "SR policies YANG model sent to IESG", due December 2019 |
2018-10-02
|
01-03 | Cindy Morgan | Added charter milestone "SRv6 Network Programming to IESG", due December 2019 |
2018-10-02
|
01-03 | Cindy Morgan | Added charter milestone "SR-IPv6 OAM sent to IESG", due July 2019 |
2018-10-02
|
01-03 | Cindy Morgan | Added charter milestone "SR-MPLS Performance Measurement to IESG", due July 2019 |
2018-10-02
|
01-03 | Cindy Morgan | Added charter milestone "SR-MPLS OAM sent to IESG", due July 2019 |
2018-10-02
|
01-03 | Cindy Morgan | Added charter milestone "SR-TE policy sent to IESG", due July 2019 |
2018-10-02
|
01-03 | Cindy Morgan | Added charter milestone "SR-MPLS configuration YANG model sent to IESG", due December 2018 |
2018-10-02
|
01-03 | Cindy Morgan | Added charter milestone "MPLS anycast sent to IESG", due October 2018 |
2018-10-02
|
01-03 | Cindy Morgan | Added charter milestone "SR-MPLS sent to IESG", due October 2018 |
2018-10-02
|
01-03 | Martin Vigoureux | New version available: charter-ietf-spring-01-03.txt |
2018-09-27
|
01-02 | Benjamin Kaduk | [Ballot comment] Alissa has some good questions, but I'm confident we can do the right thing. Thanks for the updates to address my previous concerns. |
2018-09-27
|
01-02 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2018-09-27
|
01-02 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-09-26
|
01-02 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-09-26
|
01-02 | Alissa Cooper | [Ballot comment] I'm not clear on the implications of the text about security considerations. If it turns out that people want to use this cross-domain, … [Ballot comment] I'm not clear on the implications of the text about security considerations. If it turns out that people want to use this cross-domain, will integrity protection be specified as a requirement? Will other security properties be specified as required in that scenario? If it turns out that the threat models require enhancements to the security properties of the underlying protocols, will the segment routing specs still be progressed even as those requirements are pitched over to other WGs, or will they not? |
2018-09-26
|
01-02 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-09-26
|
01-02 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-09-25
|
01-02 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-09-25
|
01-02 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2018-09-25
|
01-02 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2018-09-24
|
01-02 | Mirja Kühlewind | [Ballot comment] This sentence is probably unnecessary as always true for all wgs: "The SPRING WG will manage its specific work items by milestones agreed … [Ballot comment] This sentence is probably unnecessary as always true for all wgs: "The SPRING WG will manage its specific work items by milestones agreed with the responsible Area Director." |
2018-09-24
|
01-02 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-09-10
|
01-02 | Cindy Morgan | Telechat date has been changed to 2018-09-27 from 2018-07-05 |
2018-09-10
|
01-02 | Cindy Morgan | WG new work message text was changed |
2018-09-10
|
01-02 | Cindy Morgan | WG review text was changed |
2018-09-10
|
01-02 | Cindy Morgan | WG review text was changed |
2018-09-10
|
01-02 | Cindy Morgan | WG review text was changed |
2018-09-10
|
01-02 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2018-09-10
|
01-02 | Martin Vigoureux | Created "Approve" ballot |
2018-09-10
|
01-02 | Martin Vigoureux | Closed "Ready for external review" ballot |
2018-09-10
|
01-02 | Martin Vigoureux | State changed to External review from Internal review |
2018-09-05
|
01-02 | Benjamin Kaduk | [Ballot comment] Thanks for the updated text and the discussion to clarify that the actual protocol development used for source routing is under the purview … [Ballot comment] Thanks for the updated text and the discussion to clarify that the actual protocol development used for source routing is under the purview of different working groups, which explains the removal of much of the text about specific work items. |
2018-09-05
|
01-02 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Block |
2018-09-05
|
01-02 | Martin Vigoureux | New version available: charter-ietf-spring-01-02.txt |
2018-07-05
|
01-01 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-07-05
|
01-01 | Alexey Melnikov | [Ballot comment] I am looking forward to hearing answers to/followup discussion of Benjamin's DISCUSS. |
2018-07-05
|
01-01 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2018-07-05
|
01-01 | Benjamin Kaduk | [Ballot block] This proposed charter has minimal text on security concerns, asserting that the scope is limited to a single trust domain and only applying … [Ballot block] This proposed charter has minimal text on security concerns, asserting that the scope is limited to a single trust domain and only applying a weak requirement to "strive to identify and address" security considerations brought up by its technologies. The text concerning a single trust domain seems to implicitly assume that there is thus no need for cryptographic assurance of the integrity and/or authenticity of origin for route information, a position whose accuracy remains unclear to me. A commitment to "strive" to do something is hardly any commitment at all, in that failing to do that thing remains consistent with the commitment. Additionally, the current charter text includes some security-related items, noting that "there are a number of serious security concerns with source routing at the IP layer", committing to define the SRv6 header so that blind attacks are never possible (and with options to provide additional security in some networks), and committing to provide a security analysis for each protocol being developed. Has anything changed in the intervening five years to render these items unnecessary? I don't see any justification for why these commitments are being abandoned. |
2018-07-05
|
01-01 | Benjamin Kaduk | [Ballot Position Update] New position, Block, has been recorded for Benjamin Kaduk |
2018-07-05
|
01-01 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-07-05
|
01-01 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-07-04
|
01-01 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2018-07-04
|
01-01 | Suresh Krishnan | [Ballot comment] Can you please add 6man as a co-ordination working group for the SRv6 Network programming item as well |
2018-07-04
|
01-01 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-07-03
|
01-01 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-07-02
|
01-01 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-06-29
|
01-01 | Spencer Dawkins | [Ballot comment] I'm balloting No Objection, but hope that people look at the SPRING/IPPM interaction I mentioned below. Otherwise, this is mostly editorial. I'm not … [Ballot comment] I'm balloting No Objection, but hope that people look at the SPRING/IPPM interaction I mentioned below. Otherwise, this is mostly editorial. I'm not sure who or what finds it advantageous to use loose routing in this text - "Full explicit control (through loose or strict path specification) can be achieved in a network comprising only SPRING nodes, however SPRING nodes must inter-operate through loose routing in existing networks and may find it advantageous to use loose routing for other network applications." I THINK the reference is to a SPRING node, which doesn't make a lot of sense to me, but I'm guessing. Does everyone else know what "specificities" are meant here? "o Operation, Administration and Management (OAM), and traffic accounting in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies." and "o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies." On "Performance Management and monitoring", I note that https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ includes Segment Routing as one of its targeted encapsulations. IPPM is Mirja's working group as of about a month ago, but I'm wondering what the overlap might be. Is this something the two groups/ADs have talked about? It might be less surprising to readers if the working group names under "Specific expected interactions" were capitalized. |
2018-06-29
|
01-01 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-06-29
|
01-01 | Martin Vigoureux | New version available: charter-ietf-spring-01-01.txt |
2018-06-29
|
01-00 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2018-06-29
|
01-00 | Amy Vezza | Telechat date has been changed to 2018-07-05 from 2013-10-24 |
2018-06-29
|
01-00 | Amy Vezza | WG action text was changed |
2018-06-29
|
01-00 | Amy Vezza | WG review text was changed |
2018-06-29
|
01-00 | Amy Vezza | WG review text was changed |
2018-06-29
|
01-00 | Amy Vezza | Created "Ready for external review" ballot |
2018-06-29
|
01-00 | Amy Vezza | State changed to Internal review from Informal IESG review |
2018-06-29
|
01-00 | Martin Vigoureux | State changed to Informal IESG review from Approved |
2018-06-29
|
01-00 | Martin Vigoureux | New version available: charter-ietf-spring-01-00.txt |
2018-03-21
|
01 | Amy Vezza | Responsible AD changed to Martin Vigoureux from Alvaro Retana |
2018-01-30
|
01 | Amy Vezza | Responsible AD changed to Alvaro Retana from Stewart Bryant |
2013-10-25
|
01 | Cindy Morgan | New version available: charter-ietf-spring-01.txt |
2013-10-25
|
01 | Cindy Morgan | State changed to Approved from IESG review |
2013-10-25
|
01 | Cindy Morgan | IESG has approved the charter |
2013-10-25
|
01 | Cindy Morgan | Closed "Approve" ballot |
2013-10-25
|
01 | Cindy Morgan | Closed "Ready for external review" ballot |
2013-10-25
|
00-18 | Cindy Morgan | WG action text was changed |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "Recharter or close WG.", due February 2016 |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "Inter-operability reports pertaining to the implementation of extensions supporting SPRING.", due January 2016 |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "Document inter-working and co-existence between the new procedures and the existing signalling and routing protocols.", due November 2015 |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "Specify the OAM mechanisms needed to support SPRING.", due November 2015 |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "Management requirements document.", due July 2015 |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "One or more control protocol extensions requirements documents. ", due July 2015 |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data planes.", due July … Added charter milestone "One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data planes.", due July 2015 |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "Specification of any required new procedures to support SPRING use cases.", due March 2015 |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "Requirements for modifications if any to IPv6 architecture to support SPRING use cases.", due January 2015 |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "Requirements for modifications if any to MPLS architecture to support SPRING use cases.", due December 2014 |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "Specification of a high-level abstract architecture for SPRING.", due November 2014 |
2013-10-24
|
00-18 | Stewart Bryant | Added charter milestone "One or more documents describing SPRING use cases.", due July 2014 |
2013-10-24
|
00-18 | Stewart Bryant | New version available: charter-ietf-spring-00-18.txt |
2013-10-24
|
00-17 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to Abstain from Block |
2013-10-24
|
00-17 | Martin Stiemerling | [Ballot comment] I'm also concerned about Sean's issues and wonder if the quoted text implies a show stopper if no secure solution can be found … [Ballot comment] I'm also concerned about Sean's issues and wonder if the quoted text implies a show stopper if no secure solution can be found at all: " As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to " |
2013-10-24
|
00-17 | Martin Stiemerling | Ballot comment text updated for Martin Stiemerling |
2013-10-24
|
00-17 | Stephen Farrell | [Ballot comment] - I agree with Sean's comment (of course:-) - "These applications" in the para after the 1st bullet list could maybe be clearer. … [Ballot comment] - I agree with Sean's comment (of course:-) - "These applications" in the para after the 1st bullet list could maybe be clearer. I guess you mean the "network functions" mentioned before. |
2013-10-24
|
00-17 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-10-24
|
00-17 | Brian Haberman | [Ballot block] I agree with Ted and will probably move to Abstain on this as well, but I want to have a discussion with the … [Ballot block] I agree with Ted and will probably move to Abstain on this as well, but I want to have a discussion with the rest IESG about Sean's point. Given the issues raised during the deprecation of the RH0 routing header in IPv6 (RFC 5095), should the charter require that the security analysis for the two types of source routing be performed before any protocol work can be published? This seems logical given the concerns raised. It is not out of the ordinary given the restrictions that have been levied in other WG charters. |
2013-10-24
|
00-17 | Brian Haberman | [Ballot Position Update] New position, Block, has been recorded for Brian Haberman |
2013-10-24
|
00-17 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-10-24
|
00-17 | Benoît Claise | [Ballot comment] OLD: In the context of this charter, 'source' means 'the point at which the explicit route is imposed. NEW: In the context of … [Ballot comment] OLD: In the context of this charter, 'source' means 'the point at which the explicit route is imposed. NEW: In the context of this charter, 'source' means 'the point at which the explicit route is imposed'. OLD: filtering, cryptographic NEW filtering, cryptographic OLD: The SPRING WG should provide OAM and the management needed to manage SPRING enabled networks. NEW: The SPRING WG should provide OAM and the management needed to manage SPRING enabled networks. - Some alignment issues with the Milestones We might consider the comments above as trivial, but when I see alignment issues in the charter pages, and the charters are in THE contracts between the IESG and the WGs, I have the feeling that this doesn't look too professional. Mea culpea: it even happens in one of my OPS charters, even if I tried hard to fix all issues. |
2013-10-24
|
00-17 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-10-23
|
00-17 | Ted Lemon | [Ballot comment] I have yet to see a reason given why this is a good idea, but the routing guys seem to want it, and … [Ballot comment] I have yet to see a reason given why this is a good idea, but the routing guys seem to want it, and I think the security requirements in the charter are probably adequate, so I'm not going to block it. I share Sean's concerns about security handwaving. |
2013-10-23
|
00-17 | Ted Lemon | [Ballot Position Update] New position, Abstain, has been recorded for Ted Lemon |
2013-10-23
|
00-17 | Richard Barnes | [Ballot comment] I agree with Sean's security concerns, especially given that security problems in the routing domain have often proven tricky to solve -- and … [Ballot comment] I agree with Sean's security concerns, especially given that security problems in the routing domain have often proven tricky to solve -- and even harder to solve post-hoc. |
2013-10-23
|
00-17 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-10-23
|
00-17 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-10-23
|
00-17 | Sean Turner | [Ballot comment] Not blocking but I'm curious whether the security analysis has to be done before they get to bring the protocol to the IESG? … [Ballot comment] Not blocking but I'm curious whether the security analysis has to be done before they get to bring the protocol to the IESG? I'd hate to follow the normal path which is yeah yeah we'll do security, but we'll probably get distracted by this cool protocol work, and then loose energy and just pass the protocol to the IESG. |
2013-10-23
|
00-17 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-10-23
|
00-17 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2013-10-23
|
00-17 | Barry Leiba | [Ballot comment] No objection to the charter text. It's not clear, though, what the milestones are specifying. For the documents, I presume it's the end … [Ballot comment] No objection to the charter text. It's not clear, though, what the milestones are specifying. For the documents, I presume it's the end of the process (publication requested). For some of the milestones, though, is it possible to meet them with a working group consensus that does not turn into a document? |
2013-10-23
|
00-17 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-10-23
|
00-17 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2013-10-23
|
00-17 | Stewart Bryant | New version available: charter-ietf-spring-00-17.txt |
2013-10-23
|
00-16 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2013-10-23
|
00-16 | Stewart Bryant | Created "Approve" ballot |
2013-10-23
|
00-16 | Stewart Bryant | State changed to IESG review from External review |
2013-10-22
|
00-16 | Stewart Bryant | New version available: charter-ietf-spring-00-16.txt |
2013-10-15
|
00-15 | Cindy Morgan | Telechat date has been changed to 2013-10-24 from 2013-10-10 |
2013-10-15
|
00-15 | Cindy Morgan | State changed to External review from Internal review |
2013-10-15
|
00-15 | Cindy Morgan | WG review text was changed |
2013-10-15
|
00-14 | Cindy Morgan | WG review text was changed |
2013-10-14
|
00-15 | Stewart Bryant | New version available: charter-ietf-spring-00-15.txt |
2013-10-14
|
00-14 | Joel Jaeggli | [Ballot comment] As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never … [Ballot comment] As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negations for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc. I believe it should be negotiations rather than negations former block, I am strongly in favor of jari's, statement. I would very much like to see the charter address first why it is believed that now it is feasible to do this when we've been down this path before. clearing. |
2013-10-14
|
00-14 | Joel Jaeggli | [Ballot Position Update] Position for Joel Jaeggli has been changed to No Objection from Block |
2013-10-14
|
00-14 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Block |
2013-10-14
|
00-14 | Benoît Claise | [Ballot comment] Thanks for addressing my BLOCK. - The ability for a node to specify a forwarding path, other than the normal shortest path, that … [Ballot comment] Thanks for addressing my BLOCK. - The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions, for example: Isn't more precise to say "that a particular flow will traverse"? I guess it depends if you have in mind the data plane (per packet) or the application using SPRING, which I believe, will be using flows |
2013-10-14
|
00-14 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Block |
2013-10-14
|
00-14 | Stewart Bryant | New version available: charter-ietf-spring-00-14.txt |
2013-10-11
|
00-13 | Stewart Bryant | New version available: charter-ietf-spring-00-13.txt |
2013-10-11
|
00-12 | Stewart Bryant | New version available: charter-ietf-spring-00-12.txt |
2013-10-10
|
00-11 | Stewart Bryant | New version available: charter-ietf-spring-00-11.txt |
2013-10-10
|
00-10 | Stewart Bryant | New version available: charter-ietf-spring-00-10.txt |
2013-10-10
|
00-09 | Stewart Bryant | New version available: charter-ietf-spring-00-09.txt |
2013-10-10
|
00-08 | Stewart Bryant | New version available: charter-ietf-spring-00-08.txt |
2013-10-10
|
00-07 | Stephen Farrell | [Ballot comment] I thnk Jari/Joel make good points that the lessons from other SR attempts should be seriously considered. I also reckon that packet injection … [Ballot comment] I thnk Jari/Joel make good points that the lessons from other SR attempts should be seriously considered. I also reckon that packet injection is probably not the only threat that should be considered, e.g. having some compromised nodes in a "trusted" domain should probably also be up for consideration. In terms of charter text that could be a very simple fix, e.g. OLD: For each data plane technology that SPRING specifies, a security analysis must be provided showing how protection is provided against an attacker disrupting the network by maliciously injecting SPRING packets. NEW: For each data plane technology that SPRING specifies, a security analysis must be provided showing how protection is provided against an attacker disrupting the network by for example, maliciously injecting SPRING packets. |
2013-10-10
|
00-07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-10-10
|
00-07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-10-10
|
00-07 | Benoît Claise | [Ballot block] - I've been trying very hard to understand this text, but failed: SPRING should both provide support for its use as … [Ballot block] - I've been trying very hard to understand this text, but failed: SPRING should both provide support for its use as an OAM tool in SPRING enabled networks, and the necessary OAM and other management tools needed to manage a SPRING enabled network. "SPRING" as a subject, it's the meant as the WG, or the SPRING protocol? Note that there are other sentences starting with "SPRING" Do you mean: The SPRING WG should provide OAM and the management needed to manage SPRING enabled networks. Which types of deliverables do you have mind? - Considering the following text as the proposed milestones: The working group will develop the following documents: o One or more documents describing SPRING use cases. o Specification of a high-level abstract architecture for SPRING and requirements for modifications to existing architectures to support SPRING. o Specification of any required new procedures to support SPRING use cases. o One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data plane. o One or more control protocol extensions requirements documents. o Document inter-working and co-existence between the new procedures and the existing signalling and routing protocols. o Inter-operability reports pertaining to the implementation of extensions supporting SPRING. My BLOCK is about: where is/are the deliverable(s) for this entry o Definition of requirements and/or management plane mechanism needed to manage and operate a SPRING enabled network. |
2013-10-10
|
00-07 | Benoît Claise | [Ballot comment] - The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, … [Ballot comment] - The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions, for example: Isn't more precise to say "that a particular flow will traverse"? I guess it depends if you have in mind the data plane (per packet) or the application using SPRING, which I believe, will be using flows - Please put the milestones in the proper section, not the charter text. |
2013-10-10
|
00-07 | Benoît Claise | [Ballot Position Update] New position, Block, has been recorded for Benoit Claise |
2013-10-10
|
00-07 | Stewart Bryant | New version available: charter-ietf-spring-00-07.txt |
2013-10-10
|
00-06 | Martin Stiemerling | [Ballot comment] Thanks to Adrian for reminding me to wear my other glasses :) |
2013-10-10
|
00-06 | Martin Stiemerling | Ballot comment text updated for Martin Stiemerling |
2013-10-10
|
00-06 | Joel Jaeggli | [Ballot block] I am strongly in favor of jari's, statement. I would very much like to see the charter address first why it is believed … [Ballot block] I am strongly in favor of jari's, statement. I would very much like to see the charter address first why it is believed that now it is feasible to do this when we've been down this path before. |
2013-10-10
|
00-06 | Joel Jaeggli | [Ballot Position Update] New position, Block, has been recorded for Joel Jaeggli |
2013-10-09
|
00-06 | Ted Lemon | [Ballot comment] I agree with the point Jari raised in his block, and with Spencer's advice about how to handle the situation where work ought … [Ballot comment] I agree with the point Jari raised in his block, and with Spencer's advice about how to handle the situation where work ought to be done in some other working group, but based on some sort of discretion winds up being done in spring. |
2013-10-09
|
00-06 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-10-09
|
00-06 | Jari Arkko | [Ballot block] Early in my AD career I had to deal with the RH0 situation, and we ended up deprecating it. Like we have, for … [Ballot block] Early in my AD career I had to deal with the RH0 situation, and we ended up deprecating it. Like we have, for all practical purposes, done with the similar IPv4 mechanisms. What had initially seen as simple and useful tools turned out to be far trickier than people believed. The RH0 deprecation was not merely an IETF action - we deployed emergency patches to many products, worried about people taking down networks, worried about code left in unupdated routers, and so on. I am not opposed to dealing with new and better mechanisms for source routing. We've since then succeeded in defining very constrained source routing models (RH2, for instance) that do not have the same problems. But if we do start the work, we need to take the concerns that torpedoed earlier designs seriously. I'll observe that the charter has no text about the security, denial-of-service, or perimeter security concerns. It also talks about cross-AS designs. And it paints a very powerful, flexible model that supports a number of different applications. The combination of having something that doesn't open up all kinds of vulnerabilities and is still flexible is particularly worrying. I'd like to understand what is our plan to address this and and I'd like to see some words in the charter text to talk about this aspect. Also, this text: "Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption other than in MPLS traffic engineering. These applications may require greater flexibility and per packet source imposed routing than can be achieved through the use of the previously defined methods." seems like it is saying that the lack of flexibility caused the mechanisms to be not used. I don't think that is what happened. It was more about the security headaches that they caused to network managers... |
2013-10-09
|
00-06 | Jari Arkko | [Ballot comment] A colleague commented that service chaining is not listed as a motivation. Should be it be? This text seemed somehow odd: "The … [Ballot comment] A colleague commented that service chaining is not listed as a motivation. Should be it be? This text seemed somehow odd: "The SPRING working group will not work on any mechanisms for use in networks that forward IPv4 packets." Did you mean that the mechanisms can only work in v6-only networks, or that the mechanisms support only v6 traffic? I think you want the latter, not the former... |
2013-10-09
|
00-06 | Jari Arkko | [Ballot Position Update] New position, Block, has been recorded for Jari Arkko |
2013-10-09
|
00-06 | Brian Haberman | [Ballot comment] I have no problems with this going to external review, but I think my English parser is broken. The "and/or" construct in the … [Ballot comment] I have no problems with this going to external review, but I think my English parser is broken. The "and/or" construct in the last three work items is confusing. Can the proposed WG define encodings, control plane mechanisms, or management plane mechanisms *without* defining the requirements for those new items? Another thing that caught my eye was the mention of loose and strict source routing. Is the group completely aware of the issues surrounding IP-layer source routing? For example, RFC 5095 deprecates a type of routing header that was found to be a vehicle for attacks (e.g., the CanSecWest reference is quite useful). |
2013-10-09
|
00-06 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-10-09
|
00-06 | Pete Resnick | [Ballot comment] Agreeing in part with Spencer's comment: Is there any reason *not* to ask the WG to recharter simply to add a work item … [Ballot comment] Agreeing in part with Spencer's comment: Is there any reason *not* to ask the WG to recharter simply to add a work item if they really to work on a change to architectures, data planes, or control or management plane protocols? We have WGs update their charters for far less impressive changes. |
2013-10-09
|
00-06 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-10-09
|
00-06 | Martin Stiemerling | [Ballot comment] I struggle to fully understand what application is meant in the below text (I am fully aware of the differences in what's an … [Ballot comment] I struggle to fully understand what application is meant in the below text (I am fully aware of the differences in what's an application in the app area and in routing): Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption other than in MPLS traffic engineering. These applications may require greater flexibility and per packet source imposed routing than can be achieved through the use of the previously defined methods. Especially, as the term applications isn't showing up before that sentence. |
2013-10-09
|
00-06 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-10-08
|
00-06 | Richard Barnes | [Ballot comment] It's not clear to me why we think this will succeed where other source-routing systems have failed. But that's probably a topic for … [Ballot comment] It's not clear to me why we think this will succeed where other source-routing systems have failed. But that's probably a topic for a separate discussion. |
2013-10-08
|
00-06 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-10-07
|
00-06 | Spencer Dawkins | [Ballot comment] I'm not objecting, especially if this goes for external review, but I'm not following this text: "Any modification of or extension to existing … [Ballot comment] I'm not objecting, especially if this goes for external review, but I'm not following this text: "Any modification of or extension to existing architectures, data planes, or control or management plane protocols must be carried out in the working groups responsible ^^^^^^^ for the architecture, data plane, or control or management plane protocol being modified and in co-ordination with this working group, but may be ^^^^^^^^^^ done in this working group after agreement with all the relevant WG chairs and responsible Area Directors." Is this saying something besides "we'll do the right thing"? The text here feels loose enough that I'm not sure why it needs to be in the charter. |
2013-10-07
|
00-06 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-10-07
|
00-06 | Sean Turner | [Ballot Position Update] New position, Yes, has been recorded for Sean Turner |
2013-10-07
|
00-06 | Adrian Farrel | [Ballot comment] I am balloting Yes, but assume this will go for external review. Just some nits... --- "per-flow state information " was probably my … [Ballot comment] I am balloting Yes, but assume this will go for external review. Just some nits... --- "per-flow state information " was probably my text. Would "per-path state information" be better? --- "is gained through a network" Maybe "can be achieved in a network" --- Formatting in the second bullet list seems to be off. --- The final bullet list... "The working group will develop the following documents:" ...can presumably be deleted and replaced with milestones. |
2013-10-07
|
00-06 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2013-10-04
|
00-06 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-10-02
|
00-06 | Stewart Bryant | New version available: charter-ietf-spring-00-06.txt |
2013-10-01
|
00-05 | Stewart Bryant | New version available: charter-ietf-spring-00-05.txt |
2013-10-01
|
00-04 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2013-10-01
|
00-04 | Stewart Bryant | WG action text was changed |
2013-10-01
|
00-04 | Stewart Bryant | WG review text was changed |
2013-10-01
|
00-04 | Stewart Bryant | Created "Ready for external review" ballot |
2013-10-01
|
00-04 | Stewart Bryant | State changed to Internal review from Informal IESG review |
2013-10-01
|
00-04 | Stewart Bryant | Placed on agenda for telechat - 2013-10-10 |
2013-10-01
|
00-04 | Stewart Bryant | Responsible AD changed to Stewart Bryant |
2013-10-01
|
00-04 | Stewart Bryant | New version available: charter-ietf-spring-00-04.txt |
2013-09-30
|
00-03 | Stewart Bryant | New version available: charter-ietf-spring-00-03.txt |
2013-09-23
|
00-02 | Stewart Bryant | New version available: charter-ietf-spring-00-02.txt |
2013-09-23
|
00-01 | Stewart Bryant | New version available: charter-ietf-spring-00-01.txt |
2013-09-20
|
00-00 | Stewart Bryant | Initial review time expires 2013-09-27 |
2013-09-20
|
00-00 | Stewart Bryant | State changed to Informal IESG review from Not currently under review |
2013-09-20
|
00-00 | Stewart Bryant | New version available: charter-ietf-spring-00-00.txt |