[spring] Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

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... :-(

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".

[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?

(1d) §4.5/§4.7 have the same issue but related to IPv4.

(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.

(1f) §4.11/§4.12 allows the processing of non-ethernet payloads, which will not
be "associated with an L2 Table T" as described.

(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?

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)?

(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.

(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?

(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?  If the node is not known to support
the PSP flavor, should it be an error to receive a packet requesting that
behavior?

If only the PSP flavor is advertised, can the Source assume that the node also
supports the non-PSP flavor?

  [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.

I have the same question about the USD flavor and the externally observable
behavior related to §4.1.

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?

(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?

(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?

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.
 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?

(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

(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.

(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?

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).

(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.

(6) §4.10/§4.11/§4.12 don't have references to the example applications
mentioned.  Please add Informative references.

(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?

(8) §5.1: I'm assuming that the last line in this section (the one starting
with S03) should be proceeded by "Note:".

(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.

(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.]

(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?

(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?

(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?

(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.

(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.

(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.

(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

s/bundle(LAG)/bundle (LAG)
Please expand LAG.