IESG,
As we had promised to the 6man WG and the Spring WG, we are contacting
you to formally appeal the declaration of WG consensus to progress
draft-ietf-spring-srv6-network-programming.
(we are cc'ing the 6man WG, the Spring WG, and the general IETF list for
the sake of transparency and openness).
* Appellants:
Fernando Gont <fgont@xxxxxxxxxxxxxxx>
Andrew Alston <Andrew.Alston@xxxxxxxxxxxxxxxxx>
Sander Steffann <sander@xxxxxxxxxxx>
* Description of the Dispute
Recently, Spring WG consensus to progress
draft-ietf-spring-srv6-network-programming was declared. However, we
believe that major concerns raised as part of the WGLC of this document
remained unaddressed at the time WG consensus was declared.
Additionally, we believe that the WGLC process has not been handled with
appropriate transparency.
A Working Group Last Call (WGLC) was initiated on December 15, 2019 for
the document draft-ietf-spring-srv6-network-programming [WGLC], by one
of Spring WG co-chairs, Bruno Decraene.
During the WGLC process, a number of concerns were raised on the
document. While there have been ongoing discussions on some of these
concerns, they remained unaddressed at the time consensus was declared,
and it is unclear if the version of the document that has been shipped
for publication has successfully addressed them, since the working group
has not been given the chance to review the document that was shipped to
the IESG for publication, with adequate time to comment. Among others,
the aforementioned concerns include:
1) Participants requested a justification for the need of PSP
(Penultimate Segment Pop). [PSP-R]
Essentially, there is no general understanding on why PSP is needed.
Additionally, there have been concerns that PSP may be harmful.
Therefore, more analysis is needed both to justify the
specification of PSP, and to identify possible drawbacks associated
with it.
2) Participants have argued that PSP violates RFC8200 [IPV6-V]
Many participants have argued that, while the wording in RFC8200 is
far from perfect, the intent of RFC8200 has been to forbid en-route
header insertion/removal; as such, PSP is in violation of RFC8200.
At the very least, draft-ietf-spring-srv6-network-programming should
note that it is employing one very specific interpretation of RFC8200
for the WG and the IETF community as a whole to have the necessary
elements to make a decision on this document when reviewing it as
part of the standardization process.
3) Participants noted that PSP violates the specification of routing
headers [SR-V]
PSP implies that the penultimate segment firstly processes a routing
header (as implied by RFC8200 and specified by RFC8754) and that,
if the penultimate segment finds that Segments Left == 0, the segment
routing header be removed. This later behaviour deviates from RFC8200
and RFC8754. As such, the working group should decide whether such
documents should be updated by a separate effort in the relevant
working group (6man). We believe that
draft-ietf-spring-srv6-network-programming cannot proceed specifying
PSP before this issue has been resolved.
4) Participants requested a more prescriptive SID format [SID]
Since SIDs are eventually employed as IPv6 addresses in the
forwarding plane, it may be necessary to specify SIDs in a more
prescriptive way. Namely, require that SIDs result in IPv6
Unicast Addresses, and that conflicts with e.g. IPv6 reserved
addresses be avoided.
5) Participants questioned whether the SID format is deployable
The draft specifies a SID format, which is automatically an IPv6
prefix format. Concerns have been raised both on-list and at
an IETF meeting about the required address space needed to deploy
the technology described in the draft. Especially because a
presented example uses a /40, which is more than many networks have.
While discussing the document early on at an IETF meeting [SIZE-V],
better data on this was promised, but never delivered. While
restricting the used prefix sizes is not appropriate in this draft,
the authors, chair and responsible AD have consistently ignored
requests for real-life examples that demonstrate that the draft is
deployable with the current RIR policies, or that cooperation with
RIRs is necessary to make it deployable in the future. This issue was
noted yet once again before WGLC consensus was declared [SIZE-L].
The request for justification of PSP was dismissed by Bruno Decraene,
noting that
"I don't think that the SPRING WG can really evaluate this point
(lack of hardware knowledge, lack of detailed information on the
hardwares). The fact that this has been implemented by some platforms
and deployed by some operators, is, to me, an indication that it is
useful for those cases." [WGLC-O].
We note that the same group that allegedly does not have the necessary
skills or information for evaluating the need for PSP is the same group
that has theoretically reached consensus to proceed with moving
draft-ietf-spring-srv6-network-programming forward on the
standardization process.
The concern that this document violates RFC8200 was dismissed [WGLC-O],
noting that an associated erratum (#5933) on RFC8200 [ERRATA] "has not
been accepted by the responsible AD". However, at the time WG consensus
was declared (February 28, 2020), the erratum had not yet been processed
by the responsible AD (the associated erratum was processed on March 2,
2020).
The concerns about whether the SID format is deployable was also
discussed off-list with the responsible AD [SID-S]. At first, the AD
seemed to be under the impression that enterprises (that often only have
a /48 available) do not use technologies such as EVPN, L3VPN and network
programming. This misjudgement of the AD has been made clear based on
real life examples. However, further requests for better examples for
the WG to be able to determine if this technology is deployable have
been ignored.
The rest of the concerns were dismissed without further comments (please
see e.g. [SID-O]).
In addition to the aforementioned technical issues, a number of
procedural concerns have been raised as a result of the WGLC of this
document, including:
1) Concerns [COI] about the conflict of interest represented by the WGLC
being handled by a Contributor (Bruno Decrane) of
draft-ietf-spring-srv6-network-programming.
In this respect, Bruno Decraene started the WGLC of this document
[WGLC], and eventually declared the outcome of the WGLC (noting that
he had handled the WGLC process [WGLC-O] because his co-chair was
unavailable), and that the responsible AD (Martin Vigoureux) would
make the formal decision to send the document to the next level.
Later on, the responsible AD (Martin Vigoureux) sent a more terse
notification to the Spring mailing-list [WGLC-O2] declaring WG
consensus to progress the document, while noting that he had
performed the evaluation of the WGLC process himself.
2) There was not enough time for the working group to review the draft
version on which consensus was declared. [REVIEW]
WG consensus [WGLC-O2] was declared for a second time (this time by
Martin Vigoureux, on March 2, 2020, at 18:53 UTC), on version
draft-ietf-spring-srv6-network-programming-11 of the document,
which had been announced on the Spring mailing-list [DRAFT-A] on
March 2, 2020, at 16:47 UTC.
3) The shepherd writeup for this document [WRITEUP] seems to be omitting
information and misrepresenting the process that took place in the
working group. At the time consensus was declared on the document
[WGLC-O] [WGLC-O2], all of the concerns listed above remained
unaddressed (e.g., please see [PSP-U] and [IPv6-U]). It took over one
month for the status of the document to be reflected on the
Datatracker. During this period of time, multiple requests were
publicly made about the status of the document [STATUS-1][STATUS-2]
[STATUS-3]. On March 11, 2020, the document shepherd claimed to be
preparing the shepherd's writeup [WRITEUP-2]. Since then, multiple
revisions of the document were published (-11 through -15),
apparently to address some of the concerns that seemed to have been
dismissed during the WGLC and when consensus to move the document
forward was declared. The resulting changes were not publicly
discussed on the mailing-list. When the status of the document was
finally updated in the Datatracker, the responsible AD noted
[WGLC-POST] that revisions published since WG consensus had been
declared addressed objections that had been raised during the WGLC of
the document. However, it is unclear if the version of the document
that has been shipped from the WG has successfully addressed them --
particularly when some of the aforementioned concerns had been raised
by multiple participants, and the corresponding document updates have
never been subject to discussion on the working group mailing-list.
While these issues might have simply been the result of mistakes while
handling the WGLC of this document, they have been unfortunate in terms
of transparency of the process and credibility of the outcome of such
process (see e.g. [PROC] and [REVIEW]).
* Requested Action
We request that the document be returned to the SPRING Working Group,
such that the aforementioned technical concerns are addressed (and the
WG has the chance to confirm they have been addressed), and that,
subsequently, a second Working Group Last Call (WGLC) be initiated on
the document. Additionally, we request that measures be taken such that
possible conflicts of interest are avoided when evaluating this second WGLC.
* References
[COI]
https://mailarchive.ietf.org/arch/msg/spring/VK75j1TlsEA1zFcQ_IjC0_g86Og/
[DRAFT-A]
https://mailarchive.ietf.org/arch/msg/spring/5W_t--Ns12g9zNhItaVe-sglwwY/
[ERRATA] https://www.rfc-editor.org/errata/eid5933
[IPV6-U]
https://mailarchive.ietf.org/arch/msg/spring/zJvAkj4joRypuJ6ibBJFFoxXDD4/
[IPV6-V]
https://mailarchive.ietf.org/arch/msg/spring/XZ_D_cfPNNzXpi4_ZbuTidMTo4k/
[IPV6-V2]
https://mailarchive.ietf.org/arch/msg/spring/Xrcclo0s4pnug9upG9rUinYMv1I/
[PROC]
https://mailarchive.ietf.org/arch/msg/spring/fXdr3-uAFSYGZN2vOGSwC7IJ8Ow/
[PSP-R]
https://mailarchive.ietf.org/arch/msg/spring/eSP4xVYVgjtCmAMGMkqHedv80jU/
[PSP-U]
https://mailarchive.ietf.org/arch/msg/spring/EuJwUeIyyXonE0aGHCqwT2fd5G8/
[REVIEW]
https://mailarchive.ietf.org/arch/msg/spring/1kPMfQIRhf7EoOqA_3jtmo6dbt4/
[SID]
https://mailarchive.ietf.org/arch/msg/spring/2ApHpreqPTS689pAEyhiZEdTf7k/
[SID-O]
https://mailarchive.ietf.org/arch/msg/spring/BhIpH8b_Z-08NSq7wre36qAtqPY/
[SID-S] Steffann, Sander, private communication. Please contact Sander
Steffan at <sander@xxxxxxxxxxx> for further details.
[SIZE-L]
https://mailarchive.ietf.org/arch/msg/spring/_SYsvWXQo9t4o2KbJuEiVS-75B4/
[SIZE-V] Colitti, L. Spring wg meeting, IETF 105.
https://youtu.be/WuoJWecyATQ?t=1241
[SR-V]
https://mailarchive.ietf.org/arch/msg/spring/Xrcclo0s4pnug9upG9rUinYMv1I/
[STATUS-1]
https://mailarchive.ietf.org/arch/msg/spring/odkMyhc1LUd-h6uHp9yNlDgnCTg/
[STATUS-2]
https://mailarchive.ietf.org/arch/msg/spring/klH4StuD4E8DhVVrgGEBIFUf0sE/
[STATUS-3]
https://mailarchive.ietf.org/arch/msg/spring/tLL_XuqUNPHzHuzhwL4-AUtVTEQ/
[WGLC]
https://mailarchive.ietf.org/arch/msg/spring/tFJ742P88QYh9Ns8N97gC8BPWA4/
[WGLC-O]
https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/
[WGLC-O2]
https://mailarchive.ietf.org/arch/msg/spring/VxWwLVXBD0gRbUb4nD_NY6lE-MI/
[WGLC-POST]
https://mailarchive.ietf.org/arch/msg/spring/egaddcV_LVAnJwHFEy98crx9LFg/
[WRITEUP]
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/shepherdwriteup/
[WRITEUP-2]
https://mailarchive.ietf.org/arch/msg/spring/tSWyFOVaKDz2OyLzzckjWhvxE5U/
Yours faithfully,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
