Hi Alvaro,
Thanks for your review. See inline with [PC].
(Note that we've just posted rev21 of the draft.)
Thanks,
Pablo.
-----Original Message-----
From: Alvaro Retana via Datatracker <[email protected]>
Sent: miércoles, 23 de septiembre de 2020 22:58
To: The IESG <[email protected]>
Cc: [email protected]; [email protected];
[email protected]; Bruno Decraene <[email protected]>; Joel Halpern
<[email protected]>
Subject: Alvaro Retana's Discuss on
draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)
Alvaro Retana has entered the following ballot position for
draft-ietf-spring-srv6-network-programming-20: Discuss
When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this introductory
paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
I am balloting DISCUSS because I find the document unclear and lacking proper
technical details around significant functionality, as reflected in my first 3
points. The fourth point is related to the registration policy (which doesn't
match the definition in rfc8126), and my last point is for the IESG to consider.
(1) Pseudocode and normative behavior
The use of pseudocode was chosen as the mechanism to specify behavior, as
explained in §4:
An implementation of the pseudocode is compliant as long as the externally
observable wire protocol is as described by the pseudocode.
Clarity in the pseudocode is essential because it is used to determine
compliance. Several places need improvement:
(1a) In §4.1/§4.13/§4.15, the pseudocode is missing an ELSE after S04, to
include the error conditions if SL != 0. A check for an error condition when
SL is decremented is also needed. As written, the pseudocode could process the
packet (SL == 0) *and* send an ICMP time exceeded message... :-(
[PC] Please check the pseudocode in rev 21. We have included the missing break
statement in S03. I believe the current pseudocode is good.
I'm using as a reference the pseudocode in §4.3.1.1/rfc8754, which includes the
same initial statement.
(1b) It would be nice if the behavior in §4.1.1 were also specified using pseudocode. As
written, I am not sure if the intent is to process any upper-layer header or only
specific ones. Is the objective for this operation to be similar to the one in
§4.3.1.2/rfc8754? Please be specific on what is meant by "allowed by local
configuration".
[PC] Yes, we can structure the text in 4.1.1 in pseudocode form. The processing
is not the same as RFC8754/Section 4.3.1.2. The “allowed by local
configuration” is to enable the processing of only specific types of
Upper-layer Headers for packets addressed to an SRv6 SID of the specific
behaviors. E.g. An operator may not wish to have BGP sessions (or in general
any TCP traffic) destined to a local SID, but may want to enable ICMPv6 packet
processing for OAM purposes.
<OLD>
4.1.1. Upper-Layer Header
When processing the Upper-layer Header of a packet matching a FIB
entry locally instantiated as an SRv6 End SID, if Upper-layer Header
processing is allowed by local configuration (e.g. ICMPv6), then
process the upper-layer header. Otherwise, send an ICMP parameter
problem message to the Source Address and discard the packet. Error
code 4 (SR Upper-layer Header Error) and Pointer set to the offset of
the upper-layer header.
</OLD>
<NEW>
4.1.1. Upper-Layer Header
When processing the Upper-layer Header of a packet matching a FIB entry locally
instantiated as an SRv6 End SID do the following:
S01. If (Upper-Layer Header type is allowed by local configuration) {
S02. Process the Upper-layer Header
S03. } Else {
S04. Send an ICMP Parameter Problem to the Source Address,
Code 4 (SR Upper-layer Header Error),
Pointer set to the offset of the Upper-layer Header,
Interrupt packet processing and discard the packet.
S05 }
Notes.
S01. An operator may not wish to have any TCP traffic destined to a local SID,
but may want to enable ICMPv6 packet processing for OAM purposes.
</NEW>
[Note: this point by itself is not DISCUSS-worthy, but §4.1.1 is used, for
different reasons, in some of the other items I point to below. That is why I
include it here.]
(1c) §4.4/§4.6: S01 of the second piece of pseudocode is an instruction for
processing a non-IPv6 upper header. However, earlier in that section, it is
specified that the SID "is associated with one or more L3 IPv6 adjacencies/an
IPv6 FIB table". How can the upper header not be IPv6 if the specification
explicitly says it has to be?
[PC] The pseudocode is convoluted. I propose to turn it around for 4.4, 4.5,
4.6 and 4.7. As an example with 4.4:
<OLD>
When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an SRv6 End.DX6 SID, the following is
done:
S01. If (Upper-Layer Header type != 41(IPv6) ) {
S02. Process as per Section 4.1.1
S03. }
S04. Remove the outer IPv6 Header with all its extension headers
S05. Forward the exposed IPv6 packet to the L3 adjacency J
</OLD>
<NEW>
When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an SRv6 End.DX6 SID, the following is
done:
S01. If (Upper-Layer Header type == 41(IPv6) ) {
S02. Remove the outer IPv6 Header with all its extension headers
S03. Forward the exposed IPv6 packet to the L3 adjacency J
S04. }
S05. Else {
S06. Process as per Section 4.1.1
S07. }
</NEW>
(1d) §4.5/§4.7 have the same issue but related to IPv4.
[PC] We’ve clarified the pseudocode on the same lines as 1c.
(1e) §4.9 also has the same issue when it specifies that "End.DX2 SID...is
associated with one outgoing interface I", but allows for the processing of
non-ethernet payloads which could then be forwarded through a different outgoing
interface.
[PC] We’ve clarified the pseudocode on the same lines as 1c.
(1f) §4.11/§4.12 allows the processing of non-ethernet payloads, which will not be
"associated with an L2 Table T" as described.
[PC] We’ve clarified the pseudocode on the same lines as 1c.
(2) §4.12 describes the only behavior that can carry an ARG. I don't
understand how it works:
Arg.FE2 is encoded in the SID as an (k*x)-bit value. These bits
represent a list of up to k OIFs, each identified with an x-bit
value. Values k and x are defined on a per End.DT2M SID basis. The
interface identifier 0 indicates an empty entry in the interface
list.
Let's assume a router has 10 possible OIFs, and the operator uses 4-bit values
to identify them; then, the ARG would take 40 bits of the SID. Is that how the
math works?
Assuming my interpretation is correct, for 20 OIFs and 5-bit values we would
need 100 bits. Considering the examples in §3.2, where a /64 is allocated to a
router, this behavior wouldn't have enough bits! I realize that maybe a better
encoding would be to use a 20-bit field, each representing an interface.
However, there would still be a limit of < 64 OIFs. Am I missing something?
[PC] For the End.DT2M behavior, Arg.FE2 is a locally allocated Ethernet Segment
Identifier that is used for split-horizon filtering as described in RFC7432.
The text that you have quoted above needs to be removed since it is trying to
describe one way of allocation (which obviously has its limitations). Instead,
we will update this text to clarify the semantics and purpose of the Arg.FE2
and its allocation method would be left as implementation specific (just
similar to an ESI label).
[PC]Please see the updated text of rev21.
I'm trying to ultimately get to the fact that there are limits to this
behavior, but they are not described in the document. Please clearly explain
any limitations and any possible workaround.
(3) The description of the flavors in §4.16 is also unclear.
The section starts with this introduction:
The PSP, USP and USD flavors are variants of the End, End.X and End.T
behaviors. For each of these behaviors these flavors MAY be
supported for a SID either individually or in combinations.
By being "variants", I interpret that the behavior is different than what is
specified in §4.1.
(3a) Some of the behaviors, as listed in Table 4, include an indication of the
flavors. How are the values interpreted? For example, the Table lists 8
different behaviors related to End:
| 1 | 0x0001 | End (no PSP, no USP) | [This.ID] |
| 2 | 0x0002 | End with PSP | [This.ID] |
| 3 | 0x0003 | End with USP | [This.ID] |
| 4 | 0x0004 | End with PSP&USP | [This.ID] |
...
| 28 | 0x001C | End with USD | [This.ID] |
| 29 | 0x001D | End with PSP&USD | [This.ID] |
| 30 | 0x001E | End with USP&USD | [This.ID] |
| 31 | 0x001F | End with PSP, USP & USD | [This.ID] |
Is value 1 what is specified in §4.1? Or does it include USD, which is not
explicitly excluded)?
[PC] This has been corrected in revision 20. Can you please recheck and let me
know? E.g. 0x0001 does not include any of the flavors.
[PC] For the remainder of the comments in this section, lets recall that a
single Segment Endpoint Behavior codepoint is bound to a SID at a segment
endpoint node. A node computing a segment list with a particular SID knows
its associated behavior. A segment endpoint node receiving a packet destined
to a locally instantiated SID performs only the processing associated with the
behavior bound to that SID. A behavior is only bound to a SID, never to a node.
(3b) If a behavior with more than one flavor is signaled, how should the
receiving node determine which one to apply? I guess that the application of
behaviors 4 or 29 depends on the number of SLs -- the expected behavior should
be clearly specified.
[PC] The segment endpoint node receiving a packet destined to a SID with
behavior 4 applies only the processing associated with the SID (I.e. behavior
4).
(3c) Is it assumed that all nodes support all behaviors? Are there mandatory
to implement behaviors? Should the behavior be advertised before it is used?
[PC] The answer to first two questions is no. For the third, if a node
computing a segment list does not know of a SID (and its behavior) it will not
be able to 'use' the SID in a segment list.
(3d) §4.16.1.2:
When a SID of PSP-flavor is processed at a non-penultimate SR Segment
Endpoint Node, the PSP behavior is not performed as described in the
pseudocode below since Segments Left would not be zero.
For example, for the End behavior, I'm assuming that behavior 1 is performed
instead of 2 (or 4, or 29, or 31) if SL != 0. Should this be done even if the
node did not advertise the non-PSP flavor?
[PC] If a SID of END behavior (1) is instantiated at a segment endpoint node, a
packet destined to that SID will only ever be processed with behavior 1.
If the node is not known to support the PSP flavor, should it be an error to
receive a packet requesting that behavior?
[PC] If a node does not support PSP, then it has not instantiated any SID with
a segment endpoint behavior including PSP, and it is not possible for it to
receive a packet destined to a local SID it has not instantiated.
If only the PSP flavor is advertised, can the Source assume that the node also
supports the non-PSP flavor?
[PC] If a SID with PSP flavor is advertised (I.e. segment endpoint behavior
codepoint 2) by a segment endpoint node, a SR source node can only expect that
SID has the behavior bound to it.
[BTW, I'm asking about advertisement because §4.16.1.1 makes the statement
that the nodes "advertise the SIDs instantiated on them via control plane
protocols as described in Section 9". Even though §9 talks about control
plane protocols are "not necessary for an SDN control plane" because "one
expects the controller to explicitly provision the SIDs".]
(3e) §4.16.2 describes the USP flavor, which is one where the endpoint consumes
the packet by processing the next header. I don't understand how the outcome
due to the extended process is different from the original one in §4.1. Can
you please explain? It seems to me that the externally observable result is
the same.
[PC] We have use-cases where the packets with SRH may be destined to
applications or host implementations running in containers. The USP flavor is
useful to remove the consumed SRH from the extension header chain before
sending over to the application stack – we’ve seen this with smartNICs. As such
the perspective on externally observability differs and hence we believe it is
needed to specify this.
I have the same question about the USD flavor and the externally observable
behavior related to §4.1.
[PC] The USD flavor specifically enables the de-encapsulation of inner IP
packet and its further forwarding (consider use-case like TI-LFA where
encapsulation is done on the PLR and de-encapsulation has to be done on the
last node of the repair list). In this case the PLR node that is crafting the
SID list wants to ensure that the last segment in the repair list is able to
perform decapsulation.
In general, the observable behavior of §4.1, USP, and USD seem the same to me.
The next two points are related.
(3f) §4.16.3 describes the USD flavor, which assumes that the decapsulation
results in a packet that can be forwarded. Can the FIB lookup result in a
local destination?
[PC] Please refer the previous comment about the use-case and so yes, we
normally expect the decapsulation results in a packet that is forwarded out.
However, the inner packet may also be destined to a local address.
(3g) Does the USD flavor mean that, for the End behavior (as described in §4.1), the
action of "process the next header in the packet" cannot result in a forwarded
packet? Same question for the USP behavior?
[PC] Please refer to the previous comments. There is no such assumptions on
neither the base End behavior nor End with USP.
(3h) The last paragraph in §4.16.3:
An implementation that supports the USD flavor in conjunction with
the USP flavor MAY optimize the packet processing by first looking
whether the conditions for the USD flavor are met, in which case it
can proceed with USD processing else do USP processing.
What are the "conditions for the USD flavor"? As far as I can tell from the
document, the only condition is for the specific behavior to be signaled. What else?
[PC] I've removed this paragraph. This is an implementation optimization and
provides no value to the pseudocode preceding it.
Going back to the questions above... When is the option to optimize possible?
Does a specific behavior have to be used? Behavior 30 (End with USP&USD)? Or
can it also optimize if behavior 3 (End with USP) is signaled?
(4) §10.2 creates a new registry with an "FCFS" registration procedure. I am assuming
that this is the same as the "First Come First Served" (no
abbreviation!) policy from rfc8126; please add a reference if that is the case.
[PC] Ack to change FCFS for “First Come First Served [RFC8126]”.
The description used is not the same as what rfc8126 specifies:
- "Requests for allocation...must include a...preferably also a brief
description of how the value will be used." Using "preferably" indicates
that a description is optional. However, it is not optional in rfc8126.
- "...brief description...may be provided with a reference to an Internet
Draft or an RFC or in some other documentation that is permanently and
readily available." There is no such requirement in rfc8126. For example,
the "Specification Required" policy requires "a permanent and readily
available public specification". Is that what you want instead?
[PC] Indeed, the current text is wrong. My bad. I've updated the text with this
diff below. Also, I’m not sure whether that paragraph is really needed. Maybe
just putting in the table “First Come First Served [RFC8126]” is sufficient as
RFC8126 already describes what is written in the text below. If it can be
removed please let me know.
<OLD>
Requests for allocation from within the FCFS range must include a
point of contact and preferably also a brief description of how the
value will be used. This information may be provided with a
reference to an Internet Draft or an RFC or in some other
documentation that is permanently and readily available.
</OLD>
<NEW>
Requests for allocation from within the First Come First Serve range must
include a
point of contact and a brief description of how the
value will be used.
</NEW>
(5) This point is for the IESG to discuss.
§4.16.1.2:
The End, End.X and End.T behaviors with PSP do not contravene
Section 4 of [RFC8200] because the destination address of the
incoming packet is the address of the node executing the behavior.
The spring WG's interpretation of rfc8200 was a central point in the appeal
presented against the WG consensus on this document. The text above, I
believe, reflects that consensus.
However, given that the document relies on the spring WG's interpretation of
rfc8200, I think it would be better if the text is explicit.
Suggestion: to add at the end of the paragraph>
This conclusion represents the consensus interpretation of the spring WG.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
(1) §3.1:
An SRv6 endpoint behavior MAY require additional information for its
processing (e.g. related to the flow or service). This information
may be encoded in the ARG bits of the SID.
The sentence is simply stating a fact, not a normative behavior. s/MAY/may
[PC] This is fixed in rev20.
(2) All the examples in §3.2 have a /48 prefix allocated to the SRv6 deployment
(and then /64s per node). Is it possible to start with a different SRv6
infrastructure allocation, a /64, or /96 maybe? If so, please include an
example. If not, please explain any limitations.
[PC] The examples are based on real deployments and as such reflect the
practical aspects of those operators SRv6 infrastructure allocation designs. It
would be counter-productive and misleading to provide artificially manufactured
examples (and then why just /96 and not something else?). The document does not
pose any limitations.
(3) §4 starts by saying that "Each FIB entry indicates the behavior associated with
a SID instance and its parameters." But the previous section (§3.3. SID
Reachability) says that "node N would advertise IPv6 prefix(es) matching the LOC
parts covering its SIDs or shorter-mask prefix" (not the behavior). IOW,
§3.3 sets the expectation of an advertisement covering just the LOC, but §4
seems to expect entries that cover the LOC+FUNC. Which one is correct?
[PC] Section 3.3 talks about the Prefix Reachability advertisement for the SRv6
Locator. Section 4, is talking about FIB entries instantiated on the SR Segment
Endpoint Node that has allocated those local SIDs – please note that they are
local entries. There is no discussion on their advertisement in Section 4. Can
you please check if the update text in Section 4 in v21 clarifies?
In the end, it may not matter which entry is in the FIB, as long as the SID is
reachable. However, the specification of the behavior feels sloppy.
(4) §4.9/§4.10: For the S04 step, perhaps decompose it into individual actions
(similar to S04-S06 in §4.7).
[PC] Fixed in rev21.
(5) §4.11/§4.12 "S05. Learn the exposed MAC Source Address..."
The note related to this step says that in "EVPN, the learning...is done via the
control plane"...but here it is done via the data plane. What, if any, is the
effect on EVPN operation? Are there issues with learning conflicting information from
different sources? It seems to me that it could be relatively easy to spoof the source
and create unexpected entries in the L2 table. Please point to the EVPN documents where
this type of operation is considered.
[PC] Indeed, text is inaccurate. I've updated the note to the following:
<OLD>
S05. In EVPN, the learning of the exposed MAC Source Address is done
via the control plane.
</OLD>
<NEW>
S03. In EVPN RFC7432, the learning of the exposed MAC Source Address is done
via control plane. In L2VPN VPLS RFC4761 RFC4762 reachability is obtained by
standard learning bridge functions in the data plane.
</NEW>
(6) §4.10/§4.11/§4.12 don't have references to the example applications
mentioned. Please add Informative references.
[PC] Ack. I’ve add the references to RFC7432, RFC4761, RFC4762, RFC8317,
RFC4761.
(7) §4.13/§4.15 instantiate a Binding SID, but only in the case where SL != 0.
What about the case where a Binding SID wouldn't require an extra encapsulation
(SL == 0)? Is there a reason that it is not supported in this document?
[PC] Such a requirement has not yet arisen. If need arises in the future, a new
behavior may be defined by a future document. This document provides the
framework and the extensibility to do so.
(8) §5.1: I'm assuming that the last line in this section (the one starting with S03)
should be proceeded by "Note:".
[PC] Fixed.
(9) §5.1: "The H.Encaps behavior is valid for any kind of Layer-3 traffic."
While it may be used for any kind of traffic, I'm assuming that there will be a
policy that determines which traffic is encapsulated using a specific SRv6
policy, right? Please be specific about that.
[PC] This document does not describe how traffic is steered into an SR Policy,
it may be steered by a route installed by BGP, a static route, some application
specific selection, etc.. The steering of a packet into an SR Policy is out of
scope of this document..
(10) §5.3: "Ethernet [IEEE.802.3_2012]" Please use the reference when Ethernet
is first used in the document. [I have the same question as Rob related to the version
of the 802.3 spec.]
[PC] Fixed in rev20.
(11) §5.3: "...MUST remove the preamble or frame check sequence (FCS) from the
Ethernet frame upon encapsulation and the decapsulating node MUST regenerate
the preamble or FCS before forwarding Ethernet frame." Which one? The
preamble can be easily recreated by the receiver, while removing the FCS may be more
problematic -- even if the FCS is not checked in transit, it seems that it would be
important to carry it. In any case, the real question here is: why use "or"?
Is it left at the discretion of the encapsulating node? Are there any considerations
when selecting?
[PC] You are correct. Corrected to the following:
<OLD>
The encapsulating node MUST remove the preamble or frame check sequence (FCS)
from the Ethernet frame upon encapsulation and the decapsulating node MUST
regenerate the preamble or FCS before forwarding Ethernet frame.
</OLD>
<NEW>
The encapsulating node MUST remove the preamble (if any) and frame check
sequence (FCS) from the Ethernet frame upon encapsulation and the decapsulating
node MUST regenerate, as required, the preamble and FCS before forwarding
Ethernet frame.
</NEW>
(12) All the headend behaviors (§5) include this text:
The push of the SRH MAY be omitted when the SRv6 Policy only contains
one segment and there is no need to use any flag, tag or TLV.
If the endpoint behavior indicates the PSP or USP flavors, what should the
receiver do? Clearly there is no SRH to pop. Is this an error or should the
receiver simply ignore the flavor?
[PC] If there is no SRH, then the SRH processing is not executed.
The PSP and USP flavors only make changes in the SRH processing pseudocode,
hence it is not executed.
(13) §6: "counter...for traffic that matched that SID and was processed correctly" Does
"processed correctly" include when the result being an ICMP error message? Or should
those be counted separately?
[PC] Packets that result in an ICMP error message or those that are dropped are
not counted as correctly processed. I've updated the text.
<OLD>
A node supporting this document SHOULD implement a pair of traffic
counter (one for packets and one for bytes) per local SID entry, for
traffic that matched that SID and was processed correctly.
</OLD>
<NEW>
A node supporting this document SHOULD implement a pair of traffic
counters (one for packets and one for bytes) per local SID entry, for
traffic that matched that SID and was processed successfully (i.e. packets
which generate ICMP Error Messages or are dropped are not counted).
</NEW>
(14) §7: I'm guessing that "flow-based hash" and "load-balancing hash" are the
same thing, is that correct? It would be nice to use consistent terminology.
[PC] Fixed.
(15) §8: A rogue node inside the SR domain may (on purpose) signal the wrong
behavior for a flow, which may result in the delivery of the traffic to the
wrong destination (potentially including destinations outside the domain),
among other things. Note that this action is possible even if the rogue node
is authenticated and authorized to generate an SRH. I didn't find this threat
mentioned in rfc8402/rfc8754.
[PC] The control plane protocol specifics are outside the scope of this
document. I am not able to parse this comment and what is it that needs to be
addressed in this document.
(16) §9.4: I'm not sure what the purpose of §9 is, as a whole. But the summary
in §9.4 puzzles me more; what is the intent? Does Table 1 indicate that, for
example, an IGP implementation should not advertise the End.B6.Encaps behavior?
Does Table 2 indicate that only BGP-LS should signal the ability to
H.Encaps.L2? I am confused about the value/intent because the text clearly
says that the control plane is outside the scope of this document.
[PC] The section provides an overview of the role of control plane routing
protocols in the advertisements of the SRv6 Locator and the SIDs along with
their behaviors – all new aspects that have been introduced in this document.
Based on the SRv6 solutions developed around the behaviors introduced in this
document, it indicates what information is expected to be advertised via which
protocol. It does not describe “how” since that is clearly outside the scope of
this document and part of the individual routing protocol extensions.
(17) [nits]
s/an network operator/a network operator
s/one billionth and one millionth of the assigned address space/one billionth
and one millionth of the available address space
s/packet's header Section 7/packet's header (Section 7)/g
[PC] Those three have been fixed.
s/bundle(LAG)/bundle (LAG)
Please expand LAG.
[PC] "(LAG)" has been removed as per the comments of another AD.
Thank you for your time Alvaro!
