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

[Ketan Talaulikar <[e-mail]>]

Hi Alvaro,

We've just posted the update with the text changes as suggested by you:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13

Thanks again for your review and input to improve the document.

Thanks,
Ketan


On Thu, Mar 17, 2022 at 11:32 PM Ketan Talaulikar <[e-mail]>
wrote:

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