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 posted an update to address some of your comments below. Please see
inline below for responses and would appreciate your suggestions to address
any outstanding issues.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-12


On Sat, Feb 19, 2022 at 3:58 AM Alvaro Retana <[e-mail]>
wrote:

> On February 18, 2022 at 10:53:20 AM, Ketan Talaulikar wrote:
>
> Hi!
>
> We're still not on the same page.
>
>
> [Cut the indentation to make it more readable.]
>
> > > > >
> ----------------------------------------------------------------------
> > > > > 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.
>
> Verifying that a label is correct is not the same as confirming that
> the Behavior is plausible for the service.
>
> I understand how the ingress PE cannot validate an unknown Behavior,
> but not validating a known Behavior is not right.  If the Behavior is
> unknown, the ingress doesn't have any idea of what the egress may do,
> but if the Behavior is known, it does!
>

KT> My concern is with us getting into very loosely and not well-defined
validation at the ingress - that too when the ingress doesn't need to
bother about the local behavior  (except for those with arguments) applied
at the egress. It is better for extensibility and interoperability to not
do validation instead. This will enable the smooth and easier introduction
of new behaviors on the egress as long as there is no hard dependency on
the ingress. Please see further below.


>
> §2 lists Behaviors that may correspond to L2/L3 Services.   The
> subsections in §5 and §6 list the Endpoint Behaviors used "in
> practice" for each of the services.
>
> This is what I would like to see:  For example, §5.1 (IPv4 VPN Over
> SRv6 Core) says that "In practice, the SRv6 Endpoint behavior is
> End.DX4 or End.DT4."  The ingress PE should then be able to validate
> that the Endpoint Behavior is one of these...and take appropriate
> actions if it isn't.  Why is that not the case?  Not taking this
> simple step opens up (as you mention) the possibility of a bug
> creeping in, but also the ability of the egress to signal any behavior
> which could result in an unexpected or incorrect action.
>

KT> Since the SRv6 SID belongs to and is instantiated on the egress, it can
signal any behavior. E.g. tomorrow someone may define behavior that
subjects the packet received at the egress router to be submitted to
Firewall/DPI before being forwarded to the CE. Except for behaviors with
arguments where the ingress needs to know in order to supply the argument
values, there is nothing behavior-specific that the ingress needs to do. We
have clarified the latter in the updated text.


>
> This type of checking is the minimum that should be done.
>

KT> We can add text for some checking for the purpose of raising
warnings/alerts for the operator if that helps.


>
>
>
> ...
> > > > >
> ----------------------------------------------------------------------
> > > > > COMMENT:
> > > > >
> --------------------------------------------------------------------
> ...
> > 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.).
>
> Yes (let me reset a little) -- this is the current text (from §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.
>

KT> The above sentence says "routable within the AS of the egress" - as in
the SRv6 SID is covered by some SRv6 Locator/Prefix that is advertised via
say an IGP. The SHOULD is there because not all SRv6 SIDs need to be
"routable". Please check
https://datatracker.ietf.org/doc/html/rfc8986#section-3.3 where there is a
discussion on non-routable SRv6 SID. We have added this reference in the
text to clarify.


>
>    When steering for SRv6 services is based on shortest path forwarding
>    (e.g., best-effort or IGP Flexible Algorithm
>    [I-D.ietf-lsr-flex-algo]) to the egress PE, the ingress PE
>    encapsulates the IPv4 or IPv6 customer packet in an outer IPv6 header
>    (using H.Encaps or H.Encaps.Red flavors specified in [RFC8986]) where
>    the destination address is the SRv6 Service SID associated with the
>    related BGP route update.  Therefore, the ingress PE SHOULD perform
>    resolvability check for the SRv6 Service SID before considering the
>    received prefix for the BGP best path computation.  The resolvability
>    is evaluated as per [RFC4271].  If the SRv6 SID is reachable via more
>    than one forwarding table, local policy is used to determine which
>    table to use.  The result of an SRv6 Service SID resolvability (e.g.,
>    when provided via IGP Flexible Algorithm) can be ignored if the
>    ingress PE has a local policy that allows an alternate steering
>    mechanism to reach the egress PE.  The details of such steering
>    mechanisms are outside the scope of this document.
>
>
> My point is that it is a requirement for the SID to be reachable --
> independent of how it is resolved: IGP, BGP, "alternate steering
> mechanisms", etc.  Otherwise it can't be used.
>
> If we agree with that then the requirement should be reflected in the
> text: s/SHOULD/MUST/g
>

KT> Thanks for clarifying. I think we are on the same page on this one. The
"SHOULD" was intended to cover the "normal" resolution mechanism (i.e. via
IGP/BGP) while the "alternate mechanisms" were the other scenarios. At the
end of the day - resolution is a MUST anyways. We have changed the SHOULD
to MUST in the above paragraph to convey this intent. There were a lot of
discussions and back/forth on this text within the WG and hence we were
being extra careful.

Thanks,
Ketan



>
>
> Thanks!
>
> Alvaro.
>