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

[Ketan Talaulikar <[e-mail]>]

Hi Alvaro,

Thanks for your detailed review and comments. Please check inline below for
responses.

We have also posted an update for the draft to address comments from you
and other reviewers:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-11


On Tue, Feb 15, 2022 at 11:29 PM Alvaro Retana via Datatracker <
[e-mail]> wrote:

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

KT> Agree. We have removed the "etc".


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

KT> The argument length cannot be validated unless the endpoint behavior is
known. The ingress PE needs to actually write the ARG part of the SID into
the SRv6 SID advertised by the egress PE when sending packets for that
service to the egress PE. Therefore, knowing that the behavior involves
argument and validating the argument length is important. We have clarified
this in the text.


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

KT> Could you clarify which attribute length you are referring to?


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

KT> The endpoint behavior is something that is associated with the SID
instantiated on the Egress PE. In most cases for VPN services, the ingress
PE simply needs to use the SID to send the packet to the egress PE. This is
much like how a context/instruction is associated with the VPN label for
MPLS - it could be per-vrf or per-ce or per-prefix - normally the ingress
PE does not care. However, with SRv6, we have behaviors that have arguments
that do require the ingress PE to be aware since it needs to set up the ARG
part of the SID in the packet encapsulation. In certain other cases, the
knowledge of the behavior on the ingress PE could enable local optimization
which we do want to preclude. Having the ability to signal the SRv6
Endpoint behavior also helps in troubleshooting and monitoring.


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

KT> Correct.


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

KT> We have fixed the figure and description to match the registry name.


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

KT> Ack. Fixed.


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

KT> Ack. It is covered by RFC8986. We have rephrased the sentence.


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

KT> If the checks in sec 3.2.1 fail, then the error handling is done as per
sec 8. Please also see the next response.


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

KT> Ack. We have added the constraints for the fields of this sub-sub-tlv
as also the clarification for handling in sec 8.


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

KT> Ack. Fixed.


>
>
> (7) §5: s/MUST choose to perform IPv6 encapsulation/MUST perform IPv6
> encapsulation
>
> To choose is not normatively enforceable; encapsulating is.
>

KT> Ack. Fixed.


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

KT> An SRv6 SID may not be routable across multiple IGP domains within a
provider network when routes are not leaked. There can be other mechanisms
like SR Policies (or other forms of tunneling) that provide reachability.
In other scenarios, due to local policy, the resolution may be desired over
an SR Policy instead of the best-effort reachability provided by IGPs.


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

KT> Ack. Updated the text.


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

KT> Ack. Fixed.


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

KT> Ack. Fixed.

Thanks,
Ketan