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 quick response and please see further inline below.

We will include these changes in the next update of the draft.


On Fri, Feb 18, 2022 at 12:30 AM Alvaro Retana <[e-mail]>
wrote:

> On February 16, 2022 at 1:28:43 PM, Ketan Talaulikar wrote:
>
>
> Ketan:
>
> Hi!
>
>
> > > ----------------------------------------------------------------------
> > > 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".
>
> Ok.  Given the rest of the text, I think that "MAY" is just expressing
> a fact, not a normative action: s/MAY/may
>

KT> Ack


>
>
> > > 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.
>
> I see that the text in -11 now says this:
>
>    Arguments may be generally applicable for SIDs of only specific SRv6
>    Endpoint behaviors (e.g., End.DT2M) and therefore the Argument length
>    MUST be set to 0 for SIDs where the Argument is not applicable.  A
>    receiver is unable to validate the applicability of arguments for
>    SRv6 Endpoint behaviors that are unknown to it and hence MUST ignore
>    SRv6 SIDs with arguments (indicated by non-zero argument length) with
>    unknown endpoint behaviors.
>
> That works for me.  It addresses the cases when the Behavior is
> unknown -- the questions below are about known and expected Behaviors.
>

KT> Thanks


>
>
>
> > > 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?
>
> Sorry, I meant the argument... :-(
>

KT> The behavior definition may or may not specify requirements of argument
lengths - the currently defined ones do not pose any limitation and so the
draft talks about zero or non-zero. We can clarify by saying something on
the lines that for behaviors where arguments apply, the argument length's
consistency must be verified against the behavior definition. Would that
address your comment?


>
>
> > > 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?
>
>
>
> ...
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> ...
>
> Just one comment:
>
>
> ...
> > > (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.
>
> If there's a route over a tunnel/SR Policy/whatever, I consider that
> routable. I am not just thinking about IGP-learned routes.  The case
> that concerns me is when the ingress PE doesn't have a route at all
> (which is possible with the SHOULD).  If a route should always exist
> (from any source) then it looks like the text should indicate a
> requirement and not a recommendation.
>

KT> The should is to allow for use-cases such as the one specified in
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-18#section-8.5
- in this case, there may not be any reachability but the local policy
indicates triggering a request to a controller to compute SR Policy path to
the BGP NH on demand and then the resolution can happen once such an SR
Policy is successfully instantiated on the node.


>
>
> Thanks for addressing my other comments



>
> Alvaro.
>

Thanks,
Ketan