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

[Alvaro Retana <[e-mail]>]

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


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



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


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


Thanks for addressing my other comments.

Alvaro.