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

[Ketan Talaulikar <[e-mail]>]

Hi Alvaro,

Regarding your discussion point, we will clarify the text related to
behaviour usage for each service and for handling of unknown/new behaviour.

I'll post the update when the submission window opens next week.

Thanks,
Ketan


On Wed, 16 Feb, 2022, 11:58 pm Ketan Talaulikar, <[e-mail]>
wrote:

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