Hi Joel,
Please check inline below.
On Sun, Mar 20, 2022 at 11:13 PM Joel Halpern Direct
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> 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, [email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>> 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/>>>
> > >
> > > 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>>>
> > >
> > > 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>>>
> > >
> > >
> > > Internet-Drafts are also available by rsync at
> > rsync.ietf.org::internet-drafts
> > >
> > >
> > > _______________________________________________
> > > I-D-Announce mailing list
> > > [email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
> > > 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>>>
> > > 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>>>
> >
> > _______________________________________________
> > BESS mailing list
> > [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > 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>>>
> >
>
