FWIW, I consider may od the issues I have raised have not been addressed.
There are several main architectural areas that this document is
modiying, that don't belong in spring's charter and possibly not even in
6man (IPv6 *maintenance* != IPv6 rearchitecture).
I'll repeat these here:
* The basic Internet architecture with its removal of extension headers
in the middle of the network.
I suggest the following rationale be considered:
1)
https://mailarchive.ietf.org/arch/msg/ipv6/2CCuZ4t3scWE3bWMJI0rkT2lCqg/
2)
https://mailarchive.ietf.org/arch/msg/ipv6/SRavS6xCwTN2Y_V6zUc3vbfFmqM/
3)
https://mailarchive.ietf.org/arch/msg/ipv6/pSPLwWa3i1_1VrxxTtlzH_3UFDc/
The fact that you guys have decided to employ one possible
interpretation of the possible bogus imprecise resulting text is
alarming.
I should remind the community that, at the time RFC8754 was adopted
by the 6man wg, it was explicitly adopted on the condition that it
would remove any text regarding header insertion removal.
* The addressing architecture -- where addresses are employed for means
other than those specified in RFC4291
It would seem to me that other uses for IPv6 address, as in this
document, should be subject of an update to RFC4291, plus discussion
in a wg that is chartered to make non-trivial changes to the IPv6
architecture. I think that probably not even 6man would be allowed to
do that.
* The processing of segment routing headers, with the PSP behavior
specified in this document .
The PSP behavior does not seem to be compliant with RFC8754 itself.
All the above not only seem to essentially step outside of spring's
charter, but also result in major architectural changes with concrete
operational implications and ramifications.
Now, if the changes were discussed in the appropriate fora, and there
was consensus to go forward (whether that's a good idea or not).. so be it.
But this looks a lot like sneaking major changes to IPv6's architecture
in a group that is not chartered to do so.
P.S.: The way this I-D progressed pre-Joel Halpern just adds on top of
that (https://www6.ietf.org/iesg/appeal/gont-2020-04-22.txt)
Thanks,
Fernando
On 1/9/20 12:35, Pablo Camarillo (pcamaril) wrote:
Hi Fernando,
As part of the IESG appeal response [1] to your points below, the authors got some action items for additional clarifications. These clarifications, in line with the WG consensus, were published in Rev16 under the guidance of the document shepherd.
Please see inline below with [PC].eduard
Regards,
Pablo.
[1] https://www6.ietf.org/iesg/appeal/response-to-gont-2020-06-02.txt
-----Original Message-----
From: last-call <last-call-bounces@xxxxxxxx> On Behalf Of Fernando Gont
Sent: jueves, 27 de agosto de 2020 4:50
To: last-call@xxxxxxxx
Cc: The IESG <iesg@xxxxxxxx>
Subject: Re: [Last-Call] Last Call: <draft-ietf-spring-srv6-network-programming-17.txt> (SRv6 Network Programming) to Proposed Standard
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.
[PC] The authors elaborated the description of PSP, including providing better description of some of the value of having the flavor available (section 4.16.1)
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.
[PC] With respect to item 2 and 3, the IESG response indicated no violation and authors noted the text in section 4.16.1.
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.
[PC] As part of the IESG guidance the authors added examples of the SID values and their usage in section 3.2, as well as demonstrating some of the alternatives in the number of bits that may be needed or can be used for the SRv6 Locator and SIDs.
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].
[PC] There has been more information added on addressing space size, particularly in section 3.2 the authors added two examples on address space usage from commercial deployments.
* 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
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
