Source Packet Routing in Networking
charter-ietf-spring-03

[Ballot block]

(3) What is the new work to be done and what are the bounds?

The charter seems extremely open-ended.  With this new charter text and absence of milestones, it isn’t clear what new work the WG will pursue or even what the bounds are to judge that a given topic is in/out of scope (beyond being SR related). The primary bounding text I see is "The SPRING WG is responsible for defining new applications for, and specifying extensions to, Segment Routing technologies. It also
serves as a forum to discuss the operational aspects of deploying and managing SR-MPLS networks." 

What is an example of an application the WG will work on right now?  What are the extensions?  Am I correct in assuming there is a maintenance role for extensions?  What are the first several that need to be worked on known now to motivate this WG?  Can those be added as milestones?

When is the WG “done”?

Can this need for latitude be further explained?

[Ballot comment]
Thank you to Alvaro Retana for his explanation on trust domains.

Thank you for the revision which clarified how new work would be accepted.

[Ballot comment]
Thanks for addressing one of my previous BLOCK point and the non-blocking COMMENT.

After discussions with the SPRING WG chairs, I am balloting ABSTAIN because the current charter is also open (i.e., the scope is mostly unlimited) :-( , so there is no ground to justify a BLOCK for the proposed draft charter, whose scope is also open.

Happy to change my ballot to a YES if the WG scope becomes more defined.

Side note: I am trusting the current SPRING WG chairs and AD for applying common sense during adoption calls & WGLC.

[Ballot comment]
Thank you for addressing my concern with the line "The SPRING WG will manage its specific work items based on WG engagement and successful adoption."

[Ballot block]
Thanks for addressing one of my previous BLOCK point and the non-blocking COMMENT.

Nevertheless, per my remaining BLOCK point, the draft charter is still too open about the scope and work items (similar to my Roman's 3rd BLOCK point)

[Ballot comment]
I also agree with Roman/Gunter's blocks and John's comments. 

Para 2:  I did find the discussion of working groups involved, data plane, management plane verbiage to be difficult to follow.

At the very least, there should be guardrails or milestones (or both).

[Ballot block]
I usually to not like to pile on DISCUSS, but this charter is not bounded, i.e., does not have a list of work items. This kind of open charter is common for OPS WGs, but not really for WGs in other areas.

What is different in `The SPRING WG will manage its specific work items based on WG engagement and successful adoption.` from the usual WG processes? Suggest removing this sentence or clarifying the difference.

[Ballot comment]
About the operations, what it the differences between "SR-MPLS network operations" and "deploying and managing SRv6" in
`It also
serves as a forum to discuss SR-MPLS network operations. The SRv6
Operations (srv6ops) WG is dedicated to the operational aspects of
deploying and managing SRv6 networks.`

[Ballot block]
I support Roman's and Gunter's block, I think those are good points that needs clarifiction.

I have blocking comment as I am trying to understand the part I copied here, what it says, but I am getting confused on what should be done in spring and what should be done in other working groups and how that should be decided

    --Any modification of -or extension to- existing
architectures, data planes, or control or management plane protocols
should be carried out in the WGs responsible for the architecture,
data plane, or control or management plane protocol being modified
and in coordination with the SPRING WG, but may be done in SPRING WG
after agreement with all the relevant WG chairs and responsible Area
Directors. --

If the responsible working group should carry out the work, then why do they need to bring that work in spring? This should be explicitly mentioned otherwise it would create confusions in future to decide what should be done where.

And rephrasing the mentioned text could help here a lot.

[Ballot block]
I support Roman's and Gunter's block, I think those are good points that needs clarifiction.

I have blocking comment as I am trying to understand the part I copied here, what it says, but I am getting confused on what should be done in spring and what should be done in other working groups and how that should be decided

  Any modification of -or extension to- existing
architectures, data planes, or control or management plane protocols
should be carried out in the WGs responsible for the architecture,
data plane, or control or management plane protocol being modified
and in coordination with the SPRING WG, but may be done in SPRING WG
after agreement with all the relevant WG chairs and responsible Area
Directors.

If the responsible working group should carry out the work, then why do they need to bring that work in spring? This should be explicitly mentioned otherwise it would create confusions in future to decide what should be done where.

And rephrasing the mentioned text could help here a lot.

[Ballot comment]
This sentence makes my brain hurt, simply because the syntax requires way too much parsing:

  Any modification of -or extension to- existing architectures, data
  planes, or control or management plane protocols should be carried
  out in the WGs responsible for the architecture, data plane, or
  control or management plane protocol being modified and in
  coordination with the SPRING WG, but may be done in SPRING WG after
  agreement with all the relevant WG chairs and responsible Area
  Directors.

(Also, the "-or extension to-" thing is just wrong, turn those dashes into commas, if that text is kept. There are some definite articles missing and stuff, too.)

I don't have a fantastic rewrite to offer, but a first attempt might be to break it into several smaller sentences, as in,

  Any modification of, or extension to, existing architectures, data
  planes, or control or management plane protocols should be carried
  out in the WGs responsible for the same. The responsible WG should
  coordinate with the SPRING WG. Alternatively, the work may be done in
  the SPRING WG after agreement with all the relevant WG chairs and
  responsible Area Directors.

I'll be interested in the response to Roman's BLOCK, and I want to echo his implicit "why aren't any milestones listed?"

[Ballot block]
(1) Is the Segment Routing Architecture (RFC8402) being revised?

  By default, Segment Routing operates within a trusted domain and
  requires the enforcement of a strict boundary to prevent Segment
  Routing packets from entering the trusted domain [rfc8402]. Some
  deployments may involve multiple trusted domains and the use of
  cross/inter-domain segments. Documents which deal with such
  situations need to include a risk analysis and use mechanisms to
  validate that the segment list is provided by an authorized entity
  and has not been modified in transit.

Aren’t these “deployment … involving multiple trusted domains” at odd with the security considerations of RFC8402?  Is this text rescoping SR from a single trusted domain to effectively the Internet (i.e., what’s the difference between the internet and cross/inter-domain segments)?

(2) What is guiding the WG's management of work items?

  The SPRING WG will manage its specific work items based on WG engagement
  and successful adoption.

What does engagement mean?

What does “successful adoption” mean?  Is “adoption” referencing IETF processes or “adoption” in the marketplace via implementations?

In what way is this a statement that scopes work or WG processes.  All items any WG should be adopted based on sufficient energy to work on them.

(3) What is the new work to be done and what are the bounds?

The charter seems extremely open-ended.  With this new charter text and absence of milestones, it isn’t clear what new work the WG will pursue or even what the bounds are to judge that a given topic is in/out of scope (beyond being SR related).

When is the WG “done”?

Can this need for latitude be further explained?

[Ballot comment]
For me the 2nd paragraph reads rather complex. What about following proposal:

<>start proposed snip<>
Work within the SPRING Working Group (WG) should avoid modifications to existing data planes that would render them incompatible with current deployments. Where possible, existing control and management plane protocols must be employed within established architectures to implement the SPRING technology. Any modifications or extensions to existing architectures, data planes, or control and management plane protocols should be undertaken in the WGs responsible for those architectures or protocols, and in coordination with the SPRING WG. However, such modifications may be conducted within the SPRING WG after obtaining agreement from all relevant WG chairs and the responsible Area Directors.
<>end proposed snip<>

In the following charter text:

"
By default, Segment Routing operates within a trusted domain and
requires the enforcement of a strict boundary to prevent Segment
Routing packets from entering the trusted domain [rfc8402].
"

Should it be documented that the purpose is to prevent packets from entering and originating within the trusted domain? If we assume that no external packets are allowed to enter, then what is the rationale for preventing packets from leaving the trusted domain? Is there a use case for packets exiting the trusted domain?

[Ballot block]
"The SPRING WG will manage its specific work items based on WG engagement and successful adoption."

Without a formal understanding of what 'WG engagement' precisely means, the boundaries of this text are unclear to me. It appears to be an open interpretation that is highly susceptible to bias in determining what constitutes 'WG engagement.' Without a clear definition, I cannot dismiss the impression that the scope of SPRING work items could potentially be manipulated.

[Ballot comment]
For me the 2nd paragraph reads rather complex. Maybe simplify the paragraph

<>start proposed snip<>
Work within the SPRING Working Group (WG) should avoid modifications to existing data planes that would render them incompatible with current deployments. Where possible, existing control and management plane protocols must be employed within established architectures to implement the SPRING function. Any modifications or extensions to existing architectures, data planes, or control and management plane protocols should be undertaken in the WGs responsible for those architectures or protocols, and in coordination with the SPRING WG. However, such modifications may be conducted within the SPRING WG after obtaining agreement from all relevant WG chairs and the responsible Area Directors.
<>end proposed snip<>

In the following charter text:

"
By default, Segment Routing operates within a trusted domain and
requires the enforcement of a strict boundary to prevent Segment
Routing packets from entering the trusted domain [rfc8402].
"

Should it be documented that the purpose is to prevent packets from entering and originating within the trusted domain? If we assume that no external packets are allowed to enter, then what is the rationale for preventing packets from leaving the trusted domain? Is there a use case for packets exiting the trusted domain?

Rechartering to reflect current state of the WG.

Some notes:

1- Generally, the proposed charter is a simplified version of the current one.

2- Instead of listing *all* the WGs that could be collaborated with, the WG
  decided to list the main ones (6man, mpls, and srv6ops) and include a
  general statement about others.

3- Given that spring is a mature WG, specific work items are not listed in the
  charter. Instead, the text "will manage its specific work items based on WG
  engagement and successful adoption.", is added.

[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?

[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."

[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.

[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.

[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.

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

[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 "

[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.

[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.

[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.

[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.

[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.

[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.

[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?

[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.

[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

[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.

[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.

[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.

[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.

[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.

[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...

[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...

[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).

[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.

[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.

[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.

[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.

[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.