[bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

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

Alvaro Retana has entered the following ballot position for
draft-ietf-bess-srv6-services-10: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am balloting DISCUSS because the document underspecifies the use of Endpoint
Behaviors. As a result, it is unclear when they should be checked, enforced,
or needed. Details follow.


The descriptions of the TLVs in §2 say (twice) that the "SRv6 Endpoint
behaviors which MAY be encoded, but not limited to, are...etc."

   The text above ends with "etc." which means there are other possible
   behaviors. That's not a great use of normative language, even if optional.
   My initial instinct was to ask you to be specific, BUT...

   The description of the SRv6 SID Information Sub-TLV (§3.1) says that "an
   unrecognized endpoint behavior MUST NOT be considered invalid", which seems
   to mean that any behavior is ok, AND...

   There's no validation specified, except for the description of the SRv6 SID
   Structure Sub-Sub-TLV (§3.2.1), where it says that the "Argument length
   MUST be set to 0 for SIDs where the Argument is not applicable". AND...

   Several of the service descriptions in §5/§6 say that "The SRv6 Endpoint
   behavior of the SRv6 SID is entirely up to the originator of the
   advertisement. In practice, the SRv6 Endpoint behavior is..."


The result is that any endpoint behavior (even unrecognized) can be used,
while also requiring a specific setting for the argument length in some cases.

How can the argument length be validated if the endpoint behavior is unknown?

Clearly (from looking at rfc8986), not all endpoint behaviors apply to the
services defined in this document. Should a receiver accept any endpoint
behavior? What should a receiver do if a known but unrelated behavior (End,
for example) is received?

What should the receiver do if the endpoint behavior is known and applicable,
but the attribute length is not set correctly?

For any specific service (IPv4 VPN Over SRv6 Core, for example, to pick one),
should the behaviors used "in practice" be enforced? What if different behavior
is advertised? Can it safely be ignored?

Why is the Endpoint Behavior included in the Sub-TLV if (from the above) it
looks like it doesn't matter?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) To make sure, the new "BGP SRv6 Service SID Flags" registry is
intended to document the allocations for the "SRv6 SID Flags" field in the
SRv6 SID Information Sub-TLV (§3.1), right?

Please say so somewhere.  It would also be nice if the name of the field (SRv6
SID Flags) and the registry (SRv6 Service SID Flags) matched.  I realize that
fitting the full name in the figure won't work, but you can either use multiple
lines (as you have already) or call the field simply "Flags," then extend
to the full name in the description of the field...or many other ways to avoid
confusion.


(2) §3.1:

      SRv6 SID Flags (1 octet): Encodes SRv6 SID Flags - none are
      currently defined.  SHOULD be set to 0 by the sender and MUST be
      ignored by the receiver.

If/when the flags are defined, the behavior specified here won't be compatible.
Instead, a behavior that assumes that some of the flags will be known in the
future would be better.  For example: any unknown flags MUST be ignored by the
receiver.


(3) §3.1: "SRv6 Endpoint Behavior...The opaque endpoint behavior (i.e., value
0xFFFF)...MUST NOT be considered invalid by the receiver."

Ok, but the opaque behavior is not defined as invalid in rfc8986 or anywhere
else (AFAIK).  rfc8986 includes a note specifically for the cases in
this document in §8.3. So this requirement is not needed.


(4) §3.2.1: "Transposition Length of 0 ... In this case, the Transposition
Offset MUST be set to 0."

What should the receiver do if the offset is not set to 0?


(5) §3.2.1: According to rfc8986, the sum of the Loc + Func + Agr <= 128.  The
inclusion of the transposition fields changes the formula to add the new
length.  Please indicate the new constraints.  What should the receiver do if
the sum of the lengths is not <= 128?


(6) §3.2.1: "Arguments MAY be generally applicable for SIDs of only specific
SRv6 Endpoint behaviors"  In this case, "MAY" is just stating a fact (specified
in rfc8986): s/MAY/may


(7) §5: s/MUST choose to perform IPv6 encapsulation/MUST perform IPv6
encapsulation

To choose is not normatively enforceable; encapsulating is.


(8) §5:

   The SRv6 Service SID SHOULD be routable within the AS of the egress
   PE and serves the dual purpose of providing reachability between
   ingress PE and egress PE while also encoding the SRv6 Endpoint
   behavior.

Is it ever ok for the SID to not be routable?  If so, when?  The "purpose of
providing reachability" requires the SID to be routable.  IOW, why is this
behavior recommended and not required?


(9) Both §5/§6 say that the "ingress PE SHOULD perform resolvability check for
the SRv6 Service SID before considering the received prefix for the BGP best
path computation."

By "resolvability check", do you mean the "Route Resolvability Condition" from
§9.1.2.1/rfc4271??  If so, please be explicit.

Given that we're talking about services, which table should be used to resolve
the SID?  This question is something that rfc4271 doesn't cover [1]. Please add
something similar to this text from rfc9012 (where the resolvability condition
is mentioned):

   The reachability condition is evaluated as per [RFC4271].  If the IP
   address is reachable via more than one forwarding table, local policy is
   used to determine which table to use.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bestpath-selection-criteria


(10) [nits]

s/multiple instances...is encountered/multiple instances...are encountered/g

Please add figure numbers to all the packet formats, etc.