Folks,
During the progress of this document within the spring wg, a number of
comments were raised, and I believe they were not successfully
addressed. Eventually, we formally Appealed to the IESG the declaration
of consensus to ship this document for publication
(https://www6.ietf.org/iesg/appeal/gont-2020-04-22.txt), and requested
that the document be returned to the working group. The appeal was based
on both technical and procedural concerns.
While our request was not granted, I believe the technical issues we
raised should be considered during this IETF LC -- particularly when at
least some of these items were not addressed in the IESG response to our
appeal (https://www6.ietf.org/iesg/appeal/response-to-gont-2020-06-02.txt).
These are the issues we expect to be considered during this IETF LC:
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].
* References
[IPV6-U]
https://mailarchive.ietf.org/arch/msg/spring/zJvAkj4joRypuJ6ibBJFFoxXD
D4/
[IPV6-V]
https://mailarchive.ietf.org/arch/msg/spring/XZ_D_cfPNNzXpi4_ZbuTidMTo
4k/
[IPV6-V2]
https://mailarchive.ietf.org/arch/msg/spring/Xrcclo0s4pnug9upG9rUinYMv
1I/
[PSP-R]
https://mailarchive.ietf.org/arch/msg/spring/eSP4xVYVgjtCmAMGMkqHedv80
jU/
[PSP-U]
https://mailarchive.ietf.org/arch/msg/spring/EuJwUeIyyXonE0aGHCqwT2fd5
G8/
[SID]
https://mailarchive.ietf.org/arch/msg/spring/2ApHpreqPTS689pAEyhiZEdTf
7k/
[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/Xrcclo0s4pnug9upG9rUinYMv
1I/
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
