Hi All,
While this review is far from complete – and I will be submitting reviews of
the rest of the document as time allows – please see below regarding the text
of the document up to and including parts of section 4.2.
Based on the below as a summary – I would argue that this document could not be
used for implementation without the benefit of significant context provided by
WG discussions. Any standards document must be able to stand without the
context of WG discussions so that an implementor can take the document, and
associated documents, and implement directly. As such, from the initial review
of the initial sections, I do not believe this document meets the threshold for
publication and needs many clarifications and edits.
In section 3 it states:
“In an SRv6 domain, the SIDs are allocated from a particular IPv6 prefix: The
Locator-Block. All SRv6 SIDs instantiated from the same Locator-Block share
the same most significant bits”
This is problematic – since my reading of the first half of this would imply
that there is a single prefix. The second half implies there could be multiple
such prefix’s – so clarity is needed.
In section 3 paragraph 4 it states:
“An SR source node constructs and compresses the SID-List depending on the
capabilities of each SR segment endpoint node that the packet should traverse,
as well as it’s own compression abilities”
For this to be implementable I would argue that it is necessary to specify how
the constructor (be it controller or otherwise) is aware of the capabilities of
each node the packet should be transverse. Effectively – how does a node know
what the nodes beneath it are capable of. A lack of knowledge of this could
lead to serious operational problems. I also question why the source node’s
own compression abilities play into this – since the source node should merely
be constructing a SID list. If indeed the node’s own compression abilities
factor into this, we return to the problem of multiple solutions.
In section 3 paragraph 7 it states:
“The compressed Segment List encoding supports any Locator-Block allocation.
While other options are supported and may provide higher efficiency, each
routing domain can be allocated a /48 prefix from a global IPv6 block (see
Section 6.2)”
I would like to understand how this aligns to draft-ietf-6man-sids or if there
is any plan to align the text.
In Section 4.1 – it states:
“When processing a SID with the NEXT-C-SID flavor, while the Argument value is
non-zero, the SR segment endpoint node constructs the next SID by copying the
SID Argument value immediately after the Locator-Block, thus overwriting the
previous SID Locator-Node and Function, and filling the least significant bits
of the argument with zeros. When the Argument value is 0, the SR segment
endpoint node instead copies the next 128-bit Segment List entry from the SRH
to the Destination Address field of the IPv6 header. In both cases, the SR
segment endpoint node then forwards the packet to the new destination. The
C-SID sequence ends with the last C-SID container.”
Since this text explicitly states that when the argument value is zero, the
following entry must be copied into the DA, this implies that an SRH is
mandatory. If this is the case, it should be explicitly stated. If not, then
descriptive text needs to be inserted to explain how this works in the absence
of an SRH. A document should be able to stand without ambiguity without a
reading of the pseudocode. This text also fails to explain what happens in the
event of an SRH being present but exhausted.
The view on a mandatory SRH is again confirmed with the pseudocode segments –
the document states that the pseudocode in 4.1.1 should be inserted between S01
and S02 of the code specified in Section 4.1 of RFC8986 – when you do that you
come to the following:
When an SRH is processed {
If (DA.Argument != 0) {
If (IPv6 Hop Limit <= 1) {
Send an ICMP Time Exceeded message to the Source Address,
Code 0 (Hop limit exceeded in transit),
interrupt packet processing and discard the packet.
}
Copy the value of DA.Argument into the bits [LBL..(LBL+AL-1)]
of the Destination Address.
Set the bits [(LBL+AL)..127] of the Destination Address to
zero.
Decrement Hop Limit by 1.
Submit the packet to the egress IPv6 FIB lookup for
transmission to the next destination.
}
If (Segments Left == 0) {
Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by
the Next Header field in the routing header.
}
If (IPv6 Hop Limit <= 1) {
Send an ICMP Time Exceeded message to the Source Address
with Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet.
}
max_LE = (Hdr Ext Len / 2) - 1
If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
}
Decrement IPv6 Hop Limit by 1
Decrement Segments Left by 1
Update IPv6 DA with Segment List[Segments Left]
Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
}
As a further note to the above pseudocode – there is an assumption made that
the reader would know that submitting a packet to the egress IPv6 FIB is a
terminating action. However, this is not unambiguous, and I think should be
made clear.
In section 4.1.2 last paragraph – it refers to pseudocode insertion between
lines S01 and S02 of the pseudocode specified in section 4.2 of RFC8986 – I am
presuming this is an incorrect reference, because there is no pseudocode in
section 4.2 of RFC8986
In section 4.1.3 last paragraph – same problem as the above – it refers to
pseudocode insertion between lines S01 and S02 of pseudocode specified in
section 4.3 of RFC8986 – section 4.3 of RFC8986 does not contain pseudocode.
In section 4.1.5 it prefers to the process in 4.14 of RFC8986 – this again
requires pseudocode modification – except my understanding is the pseudocode
that requires modification is in 4.13 of RFC8986 – this level of abstraction
makes this incredibly difficult to read.
In section 4.1.7 it states – “The pseudocodes defined in Section 4.1.1,
Sections 4.1.2 and Section 4.1.3 of this document are inserted at the beginning
of the modified upper-layer header processing defined in Section 4.16.3 of
RFC8986 for End, End.X and End.T respectively.” This is a little ambiguous. I
am presuming that this should say “inserted directly after S01 of the
pseudocode specified in Section 4.16.3 of RFC8986. I make this assumption
since the pseudocode specified in the sections listed (4.1.1, 4.1.2 and 4.1.3)
is terminating in nature, and as such if you inserted this before S01 (at the
beginning) the remaining pseudocode would not be processed.
In section 4.2 the text states that the first SID is copied into the DA field
of the IPv6 header, either at the SR source node, or at the previous SR segment
endpoint node. This text is a direct contradiction of statements that this is
a single solution since the source node will only be inserting a SID list into
an SRH – and hence only acting at a control plane layer. While theoretically
this can be done in the control plane when assembling the encapsulated packet,
the text itself does not state that and as written, the head end node would
need to have knowledge of REPLACE behavior at more than a control plane layer.
Thanks
Andrew
Internal All Employees
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
