Re: [bess] I-D Action: draft-ietf-bess-srv6-services-13.txt

Hi Joel,

Please see inline below.

On Sun, Mar 20, 2022 at 11:34 AM Joel M. Halpern <jmh@joelhalpern.com>
wrote:

> I seem to be missing something.
>
> The ingress PE (domain edge) applies the destination SID (possibly as
> part of a SID list).  Either it is deciding to use the destination SID,
> or something else is deciding to use the destination SID.
>

KT> The ingress PE is deciding. Something else (e.g., a controller) may
decide the path (e.g., SID list for SR Policy) but the Service/VPN context
is signaled via BGP from egress to ingress PE.

>
> Ignoring the issue of argument manipulation, if the Ingress PE is
> deciding on its own, doesn't it have to understand the meaning of the
> behavior in order to decide that it wants to invoke it?
>

KT> The ingress PE is not invoking anything and hence it doesn't need to
understand the meaning of the behavior (with some exceptions like when it
needs to supply the argument). Ingress PE is simply setting the received
SRv6 Service SID as the IPv6 DA in the outer encapsulation (let's keep
aside SR Policy for now). When this packet reaches the egress PE, it ends
up invoking the behavior corresponding to the locally instantiated SRv6 SID
on the egress PE. As an analogy - whether the label signaled by the
egres PE is per-VRF or per-CE does not affect the processing at ingress PE.

> If something else provides the SID list and the rules for which traffic
> should use it (e.g. the SR policy or similar) then the Ingress PE would
> not seem to need such understanding.
>

KT> The situation is the same even in this case.

Thanks,
Ketan

>
> Yours,
> Joel
>
> On 3/20/2022 1:37 AM, Ketan Talaulikar wrote:
> > Hi Joel,
> >
> > There is no implicit assumption such as the one you refer to. The
> > ingress PE does not need to do anything specific with the choice of the
> > behavior picked by the egress PE except where the behavior involves the
> > use of argument. Ingress PE does need to know & support the specific
> > behavior when it needs to supply the argument based on the behavior
> > definition.
> >
> > Thanks,
> > Ketan
> >
> > On Sun, Mar 20, 2022 at 10:56 AM Joel M. Halpern <jmh@joelhalpern.com
> > <mailto:jmh@joelhalpern.com>> wrote:
> >
> >     I keep reading the description of the handling of unknown endpoint
> >     behaviors.
> >
> >     It seems there is an implicit assumption that I would think it would
> be
> >     helpful to make explicit.  As far as I can tell, a head end would
> never
> >     choose based purely based on local policy to make use of an
> advertised
> >     SID with an unknown behavior?  However, a head end might use such a
> >     ISD,
> >     without knowing what it was really asking, if so instructed by a
> policy
> >     engine (e.g. SR Policy)?
> >
> >     Yours,
> >     Joel
> >
> >     On 3/19/2022 11:32 PM, internet-drafts@ietf.org
> >     <mailto:internet-drafts@ietf.org> wrote:
> >      >
> >      > A New Internet-Draft is available from the on-line
> >     Internet-Drafts directories.
> >      > This draft is a work item of the BGP Enabled ServiceS WG of the
> IETF.
> >      >
> >      >          Title           : SRv6 BGP based Overlay Services
> >      >          Authors         : Gaurav Dawra
> >      >                            Clarence Filsfils
> >      >                            Ketan Talaulikar
> >      >                            Robert Raszuk
> >      >                            Bruno Decraene
> >      >                            Shunwan Zhuang
> >      >                            Jorge Rabadan
> >      >       Filename        : draft-ietf-bess-srv6-services-13.txt
> >      >       Pages           : 34
> >      >       Date            : 2022-03-19
> >      >
> >      > Abstract:
> >      >     This document defines procedures and messages for SRv6-based
> BGP
> >      >     services including L3VPN, EVPN, and Internet services.  It
> >     builds on
> >      >     RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and
> RFC7432
> >      >     "BGP MPLS-Based Ethernet VPN".
> >      >
> >      >
> >      > The IETF datatracker status page for this draft is:
> >      > https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
> >     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>
> >      >
> >      > There is also an htmlized version available at:
> >      >
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13
> >     <
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13>
> >      >
> >      > A diff from the previous version is available at:
> >      >
> >     https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13
> >     <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>
> >      >
> >      >
> >      > Internet-Drafts are also available by rsync at
> >     rsync.ietf.org::internet-drafts
> >      >
> >      >
> >      > _______________________________________________
> >      > I-D-Announce mailing list
> >      > I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
> >      > https://www.ietf.org/mailman/listinfo/i-d-announce
> >     <https://www.ietf.org/mailman/listinfo/i-d-announce>
> >      > Internet-Draft directories: http://www.ietf.org/shadow.html
> >     <http://www.ietf.org/shadow.html>
> >      > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> >
> >     _______________________________________________
> >     BESS mailing list
> >     BESS@ietf.org <mailto:BESS@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/bess
> >     <https://www.ietf.org/mailman/listinfo/bess>
> >
>