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

[Ketan Talaulikar <[e-mail]>]

Hi Alvaro,

Please check inline below for a few responses.


On Fri, Feb 18, 2022 at 5:52 PM Alvaro Retana <[e-mail]>
wrote:

> On February 18, 2022 at 12:23:03 AM, Ketan Talaulikar wrote:
>
>
> Hi!
>
>
> > > > >
> ----------------------------------------------------------------------
> > > > > DISCUSS:
> > > > >
> ----------------------------------------------------------------------
> ...
> > > > > 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?
> ...
> > > > > 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?
>
> These two are related: Should only specific behaviors (per service) be
> accepted?
>
> If yes, I need you to specify which are those behaviors and what
> happens if a different (known) one is received.
>
> If no, what does it mean for the service if an unrelated behavior is
> advertised?
>

KT> So, this would be a result of a bug (?) on the egress PE that signals a
wrong behavior. Since the receiver is not validating, the service traffic
would still arrive at the egress PE but the handling might be erroneous due
to wrong behavior. The issue still manifests on the egress PE due to its
bug. Somewhat similar to what might happen if the egress PE were to signal
a label associated with a wrong context/service as a VPN label in MPLS VPNs.


>
>
>
>
> > > > > 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?
>
> Yes, it would.
>

KT> Thanks.


>
> Also, if the verification fails then what?
>

KT> That is already covered by the existing text in sec 8 - such a route
would be considered ineligible during the selection of the best path by the
receiver.


>
>
>
> > > > >
> ----------------------------------------------------------------------
> > > > > 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.
>
> The end result is that the SID MUST be reachable before the ingress
> node can do anything with it.  As you say: "the resolution can happen
> once such an SR Policy is successfully instantiated on the node".  The
> mechanisms to provide that resolution (IGP, manual configuration,
> controller, etc.) is independent of the requirement for there to be
> reachability.
>

KT> I believe we were discussing the part of the "SID being routable" as in
via routing protocol (i.e. IGP/BGP transport). The next paragraph is one
that covers the base BGP "resolvability" part and does elaborate on the
various mechanisms like "alternate steering mechanisms" (e.g. any tunnel,
SR Policy, etc.).

Thanks,
Ketan



>
> Alvaro.
>