[lacnog] Fwd: Appeal to the IESG re WGLC of draft-ietf-spring-srv6-network-programming

Fernando Gont fgont en si6networks.com
Mie Abr 22 23:44:32 GMT+3 2020


Esta es la primera vez que hago, junto a otros colegas, una apelación 
ante la IESG.

La apelación está bien detallada, y llena de referencias. Cada uno saque 
sus propias conclusiones en materia de transparencia y credibilidad del 


-------- Forwarded Message --------
Subject: Appeal to the IESG re WGLC of 
Date: Wed, 22 Apr 2020 23:26:58 -0300
From: Fernando Gont <fgont en si6networks.com>
To: The IESG <iesg en ietf.org>
CC: Andrew Alston <Andrew.Alston en liquidtelecom.com>, Sander Steffann 
<sander en steffann.nl>, spring en ietf.org <spring en ietf.org>, 6man en ietf.org 
<6man en ietf.org>, 'ietf en ietf.org' <ietf en ietf.org>


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 
(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 en si6networks.com>
Andrew Alston <Andrew.Alston en liquidtelecom.com>
Sander Steffann <sander en steffann.nl>

* 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, 

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

    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



[ERRATA] https://www.rfc-editor.org/errata/eid5933










[SID-S] Steffann, Sander, private communication. Please contact Sander 
Steffan at <sander en steffann.nl> for further details.


[SIZE-V] Colitti, L. Spring wg meeting, IETF 105. 











Yours faithfully,
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Más información sobre la lista de distribución LACNOG