Hi Joel,
Please check inline below.
On Mon, Mar 21, 2022 at 2:19 PM Joel M. Halpern <j...@joelhalpern.com
<mailto:j...@joelhalpern.com>> wrote:
Okay, so for all cases where the argument length is non-zero, the
receiver can use the advertisement only if they understand the behavior?
KT> Yes.
What does it mean for the receiver to "use" the behavior when the
argument length is zero?
KT> "Use" would be to put the SRv6 Service SID received from the egress
PE via BGP signaling as the IPv6 DA on the outer IPv6 encapsulation
introduced on the ingress PE and routing this encapsulated packet
towards the egress PE.
Yours,
Joel
PS: By "transport" I was (sloppily, sorry) referring to the
transposition mechanism, which seemed to be defined by the argument
length, transposition offset, and the route type. From what you say,
that does not suffice to fill in the argument field. If so, the
exposition in the draft should be improved.
KT> The transposition scheme is limited to the BGP encoding alone and
not related to the rest of the functionality. Perhaps I am still not
getting your point here?
Thanks,
Ketan
On 3/21/2022 4:41 AM, Ketan Talaulikar wrote:
> Hi Joel,
>
> Please check inline below.
>
>
> On Sun, Mar 20, 2022 at 11:13 PM Joel Halpern Direct
> <jmh.dir...@joelhalpern.com <mailto:jmh.dir...@joelhalpern.com>
<mailto:jmh.dir...@joelhalpern.com
<mailto:jmh.dir...@joelhalpern.com>>> wrote:
>
> I have reread the draft. let me try asking the quesiton the
> opposite way.
>
> 1) If the argument length is zero, then an Ingress PE will always
> ignore
> the SRv6 Endpoint behavior, as it will not do anything
differently
> if it
> understands or does not understand the behavior.
>
>
> KT> The draft does not say that the behavior is to be ignored. It
says
> that ingress PE can still use such behaviors even if they are
> unknown/unsupported.
>
>
> 2) If the argument length is non-zero, but it is being filled
in by the
> transportion mechanism, then again the Ingress PE might as
well ignore
> the SRv6 Endpoint Behavior Information
>
>
> KT> RFC8986 does not talk about any behavior where the argument is
> filled by the transport mechanism. Neither does this draft.
>
>
> 3) If other information such as the use of the MPLS ESI or
label (EVPN
> Auto-Discovery) is used to fill in the argument, this is
determined
> from
> the type information and not from the SRv6 Endpoint Behavior?
>
>
> KT> Just the route type information is not sufficient and
understanding
> of the behavior is also required before it can be used.
>
>
> 4) If none of those cases apply, and the SRv6 Endpoint
Behavior is
> known
> by the Ingress PE, and that behavior reuries other
manipulation of the
> argument field of the resulting SID, then the Ingress PE acts
on that
> information? And the advertiser has to somehow ensure that all
> receivers will correctly understand the necessary manipulation?
>
>
> It seems that carrying the SRv6 Endpoint Behavior, and trying to
> describe when it needs to be understood, is for a use case
that is not
> even covered in the document?
>
>
> KT> I am not sure that I understand the above two paragraphs very
well.
> For any behavior where arguments are used, the
understanding/support for
> the behavior is required at the ingress PE - to set the argument
part of
> the SID before sending the packets towards the egress PE. Where
> arguments are not used, the SID can be used, as signaled, by the
ingress
> PE even if it does not understand the behavior.
>
> Thanks,
> Ketan
>
>
> Yours,
> Joel
>
> On 3/20/2022 2:54 AM, Ketan Talaulikar wrote:
> > Hi Joel,
> >
> > Please see inline below.
> >
> > On Sun, Mar 20, 2022 at 11:34 AM Joel M. Halpern
> <j...@joelhalpern.com <mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>
> > <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com <mailto:j...@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
> > <j...@joelhalpern.com <mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>
> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>>
> > > <mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com> <mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>>
> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com <mailto:j...@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-dra...@ietf.org
<mailto:internet-dra...@ietf.org>
> <mailto:internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>>
> > <mailto:internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>
> <mailto:internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>>>
> > > <mailto:internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>
> <mailto:internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>>
> > <mailto:internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>
> <mailto:internet-dra...@ietf.org
<mailto:internet-dra...@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/>
>
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>>
> >
>
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>
>
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>>>
> > >
> >
>
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>
>
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>>
> >
>
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>
>
<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>
>
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13>>
> >
>
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13>>>
> > >
> >
>
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13>> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13> <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>
>
<https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>>
> >
>
<https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13> <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>>>
> > >
> >
>
<https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13> <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>> <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13> <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-annou...@ietf.org
<mailto:i-d-annou...@ietf.org>
> <mailto:i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>>
<mailto:i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
> <mailto:i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>>>
> > <mailto:i-d-annou...@ietf.org
<mailto:i-d-annou...@ietf.org> <mailto:i-d-annou...@ietf.org
<mailto:i-d-annou...@ietf.org>>
> <mailto:i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
<mailto:i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>>>>
> > > >
https://www.ietf.org/mailman/listinfo/i-d-announce
<https://www.ietf.org/mailman/listinfo/i-d-announce>
> <https://www.ietf.org/mailman/listinfo/i-d-announce
<https://www.ietf.org/mailman/listinfo/i-d-announce>>
> > <https://www.ietf.org/mailman/listinfo/i-d-announce
<https://www.ietf.org/mailman/listinfo/i-d-announce>
> <https://www.ietf.org/mailman/listinfo/i-d-announce
<https://www.ietf.org/mailman/listinfo/i-d-announce>>>
> > >
<https://www.ietf.org/mailman/listinfo/i-d-announce
<https://www.ietf.org/mailman/listinfo/i-d-announce>
> <https://www.ietf.org/mailman/listinfo/i-d-announce
<https://www.ietf.org/mailman/listinfo/i-d-announce>>
> > <https://www.ietf.org/mailman/listinfo/i-d-announce
<https://www.ietf.org/mailman/listinfo/i-d-announce>
> <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> <http://www.ietf.org/shadow.html
<http://www.ietf.org/shadow.html>>
> <http://www.ietf.org/shadow.html
<http://www.ietf.org/shadow.html> <http://www.ietf.org/shadow.html
<http://www.ietf.org/shadow.html>>>
> > > <http://www.ietf.org/shadow.html
<http://www.ietf.org/shadow.html>
> <http://www.ietf.org/shadow.html
<http://www.ietf.org/shadow.html>>
> > <http://www.ietf.org/shadow.html
<http://www.ietf.org/shadow.html>
> <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>
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>
> > <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>>
> > > <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>
> > <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> <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>
<mailto:BESS@ietf.org <mailto:BESS@ietf.org>> <mailto:BESS@ietf.org
<mailto:BESS@ietf.org>
> <mailto:BESS@ietf.org <mailto:BESS@ietf.org>>>
<mailto:BESS@ietf.org <mailto:BESS@ietf.org> <mailto:BESS@ietf.org
<mailto:BESS@ietf.org>>
> > <mailto:BESS@ietf.org <mailto:BESS@ietf.org>
<mailto:BESS@ietf.org <mailto:BESS@ietf.org>>>>
> > > https://www.ietf.org/mailman/listinfo/bess
<https://www.ietf.org/mailman/listinfo/bess>
> <https://www.ietf.org/mailman/listinfo/bess
<https://www.ietf.org/mailman/listinfo/bess>>
> > <https://www.ietf.org/mailman/listinfo/bess
<https://www.ietf.org/mailman/listinfo/bess>
> <https://www.ietf.org/mailman/listinfo/bess
<https://www.ietf.org/mailman/listinfo/bess>>>
> > > <https://www.ietf.org/mailman/listinfo/bess
<https://www.ietf.org/mailman/listinfo/bess>
> <https://www.ietf.org/mailman/listinfo/bess
<https://www.ietf.org/mailman/listinfo/bess>>
> > <https://www.ietf.org/mailman/listinfo/bess
<https://www.ietf.org/mailman/listinfo/bess>
> <https://www.ietf.org/mailman/listinfo/bess
<https://www.ietf.org/mailman/listinfo/bess>>>>
> > >
> >
>