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

From: [email-masked]
Date: Sat, 19 Mar 2022 20:32:29 -0700

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/

There is also an htmlized version available at:
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

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 20 Mar 2022 01:25:44 -0400

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-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 20 Mar 2022 11:07:00 +0530

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-masked]>
wrote:

> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 20 Mar 2022 02:04:51 -0400

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.

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?
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.

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-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     On 3/19/2022 11:32 PM, [email-masked]
>     <mailto:[email-masked]> wrote:
>      >
>     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>
>      >
>     <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13>
>      >
>     <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>
>      >
>      >
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/i-d-announce>
>     <http://www.ietf.org/shadow.html>
>     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/bess>
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 20 Mar 2022 12:24:21 +0530

Hi Joel,

Please see inline below.

> 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.

> 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.

> not seem to need such understanding.

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

Thanks,
Ketan

> >     <
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13>
> >      >

---

From: Joel Halpern Direct <[email-masked]>
Date: Sun, 20 Mar 2022 13:43:05 -0400

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.

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

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?

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?

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-masked] 
> decide the path (e.g., SID list for SR Policy) but the Service/VPN 
> context is signaled via BGP from egress to ingress PE.
> 
> 
> 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.
> 
>      > On Sun, Mar 20, 2022 at 10:56 AM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     SID with an unknown behavior?  However, a head end might use
>     such a
>      >     ISD,
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>> 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
>      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > 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>>
>      >      > 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>>
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>>
>      >
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 21 Mar 2022 14:11:30 +0530

Hi Joel,

Please check inline below.

> 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.

> 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.

> 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.

> 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

> >      >      >     services including L3VPN, EVPN, and Internet
> services.  It
> >      >     builds on
> 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://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>>
> >      >      >
> >      >      >
> >      >      > Internet-Draft directories:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Mar 2022 04:49:16 -0400

Okay, so for all cases where the argument length is non-zero, the 
receiver can use the advertisement only if they understand the behavior?

What does it mean for the receiver to "use" the behavior when the 
argument length is zero?  What can the receiver do differently based on 
understanding the endpoint behavior?

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.

On 3/21/2022 4:41 AM, Ketan Talaulikar wrote:
> On Sun, Mar 20, 2022 at 11:13 PM Joel Halpern Direct 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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.
> 
> 
> KT> RFC8986 does not talk about any behavior where the argument is 
> filled by the transport mechanism. Neither does this draft.
> 
> 
> KT> Just the route type information is not sufficient and understanding 
> of the behavior is also required before it can be used.
> 
> 
> 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 Sun, Mar 20, 2022 at 11:34 AM Joel M. Halpern
>      >      > 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
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> 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-masked]
>     <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> 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/>>>
>      >      >      >
>      >      >      > 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>>>
>      >      >      >
>      >      >      > 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>>>
>      >      >      >
>      >      >      >
>      >      >      > Internet-Drafts are also available by rsync at
>      >      >     rsync.ietf.org::internet-drafts
>      >      >      >
>      >      >      >
>      >      >      > _______________________________________________
>      >      >      > I-D-Announce mailing list
>      >      >      > [email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > 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>>>
>      >      >      > 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>>>
>      >      >
>      >      >     BESS mailing list
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > https://www.ietf.org/mailman/listinfo/bess
>      >      >     <https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>>>
>      >      >
>      >
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 21 Mar 2022 16:00:03 +0530

Hi Joel,

> receiver can use the advertisement only if they understand the behavior?

KT> Yes.

> 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.

> What can the receiver do differently based on

KT> The draft does not specify anything in this regard.

> 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

> >      >      > ingress PE does not need to do anything specific with the
> >     choice
> >      >     of the
> >      >      > <mailto:[email-masked] <mailto:[email-masked]>
> >      >      >     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
> >      >      >     without knowing what it was really asking, if so
> >     instructed
> >      >     by a policy
> >      >      >     engine (e.g. SR Policy)?
> >      >      >
> >      >      >     Yours,
> >      >      >     Joel
> >      >      >
> >      >      >      > This draft is a work item of the BGP Enabled
> >     ServiceS WG
> >      >     of the IETF.
> >      >      >      >
> >      >      >      >     This document defines procedures and messages
> for
> >      >     SRv6-based BGP
> >      >      >      >     RFC4364 "BGP/MPLS IP Virtual Private Networks
> >     (VPNs)"
> >      >     and RFC7432
> 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://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13> <
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>>>
> >      >      >      >
> >      >      >      >

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 21 Mar 2022 06:38:45 -0400

In line.

On 3/21/2022 6:30 AM, Ketan Talaulikar wrote:
> On Mon, Mar 21, 2022 at 2:19 PM Joel M. Halpern <[email-masked] 
> 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.

that was the use I had understood was intended by the draft.  What I do 
not see is any way that the endpoint behavior (and / or the 
understanding or lack of understanding thereof) makes any difference.

> KT> The draft does not specify anything in this regard.

I was prompted to ask this by wondering,, if the behavior could matter, 
if the receiver did not understand the behavior, how could it know there 
was a problem.  If this is strictly tied to the argument length being 
non-zero, then I can at least understand it.

If there is some other case, then there appears to be a determinancy 
problem.   I suspect his could be resolved by having the sender only use 
a behavior other than 0xFFFF if the SID can only be used by an Ingress 
who understand the specified (non 0xFFF) behavior??

Yours,
Joe;

> 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
> 
> 
>      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >     the SRv6 Endpoint behavior, as it will not do anything
>     differently
>      >     if it
>      >     Auto-Discovery) is used to fill in the argument, this is
>     determined
>      >     from
>      >     4) If none of those cases apply, and the SRv6 Endpoint
>     Behavior is
>      >     known
>      >      > Please see inline below.
>      >      >
>      >      > On Sun, Mar 20, 2022 at 11:34 AM Joel M. Halpern
>      >      >     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-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> 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-masked]
>     <mailto:[email-masked]>>>
>      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>> 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        :
>      >      >      >      >       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/>>>>
>      >      >      >      >
>      >      >      >      > 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-masked]
>     <mailto:[email-masked]>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >      >
>     <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>>>>
>      >      >      >      > 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>>>>
>      >      >      >
>      >      >      >     BESS mailing list
>      >      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      > https://www.ietf.org/mailman/listinfo/bess
>      >      >      >     <https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>>>>
>      >      >      >
>      >      >
>      >
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 21 Mar 2022 16:40:54 +0530

Hi Joel,

Please check inline below with KT2.

> non-zero, then I can at least understand it.

KT2> The use of the arguments is the main thing when it comes to
interoperability. Otherwise, the actual processing of the SRv6 SID behavior
definition is actually happening only at the egress PE that owns and has
instantiated that SRv6 SID. Besides this, the info about the behavior can
be used for monitoring/troubleshooting.

> who understand the specified (non 0xFFF) behavior??

KT2> Yes, the use of opaque (0xFFFF) is allowed for such scenarios.

Thanks,
Ketan

> >      >     1) If the argument length is zero, then an Ingress PE will
> always
> >      >     ignore
> >      >      >     The ingress PE (domain edge) applies the destination
> SID
> >      >     (possibly as
> >      >      > 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
> >      >      > egress PE, it ends up invoking the behavior corresponding
> >     to the
> >      >     locally
> >      >      > label signaled by the egres PE is per-VRF or per-CE does
> not
> >      >     affect the
> >      >      >     If something else provides the SID list and the rules
> for
> >      >     which traffic
> >      >      >      > There is no implicit assumption such as the one you
> >     refer
> >      >     to. 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
> >      >      >      >
> >      >      >      > <mailto:[email-masked]
> >      >      >      >     I keep reading the description of the handling
> >     of unknown
> >      >      >     endpoint
> >      >      >      >     behaviors.
> >      >      >      >
> >      >      >      >     SID with an unknown behavior?  However, a head
> end
> >      >     might use
> >      >      >     such a
> >      >      >      >     ISD,
> >      >      >      >      > A New Internet-Draft is available from the
> >     on-line
> >      >      >      >      >          Title           : SRv6 BGP based
> >      >      >      >      >     This document defines procedures and
> >     messages for
> >      >      >     SRv6-based BGP
> 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://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
> >      >     <mailto:[email-masked] <mailto:[email-masked]
> >>>
> >      >      >     <mailto:[email-masked]
> >      >      > http://www.ietf.org/shadow.html
> >      >      >     <mailto:[email-masked] <mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Mar 2022 07:16:08 -0400

Top-posting, but copying the rest for cotnext if people need it.

What I was trying to suggest is that the presence in the advertissement 
of an endpoint behavior other than oxFFFF be defined to be the signal 
that the Ingress needs to understand the behavior to use the 
advertisement.
At one point in our conversation, I had thought the arg length being 
non-zero was that indication, but you indicated otherwise.

If we do not do one or the other, and an ingress receives an 
advertisement with an unknown behavior, how does it determine if it can 
use the advertised SID?  Currently, it seems to be the case that it 
assumes that it can use it.  Which seems odd if it has meaning.

Yours,
Joel

On 3/21/2022 7:10 AM, Ketan Talaulikar wrote:
> On Mon, Mar 21, 2022 at 4:08 PM Joel Halpern Direct 
>      > On Mon, Mar 21, 2022 at 2:19 PM Joel M. Halpern
> interoperability. Otherwise, the actual processing of the SRv6 SID 
> behavior definition is actually happening only at the egress PE that 
> owns and has instantiated that SRv6 SID. Besides this, the info about 
> the behavior can be used for monitoring/troubleshooting.
> 
> 
>      >      > Please check inline below.
>      >      >
>      >      >
>      >      > On Sun, Mar 20, 2022 at 11:13 PM Joel Halpern Direct
>      >      > <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>>> 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
>      >      >      >     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-masked]
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >      > <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>> 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-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>>>>
>      >      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>> 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/>>>>>
>      >      >      >      >      >
>      >      >      >      >      > 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
>      >      >      >      >      > [email-masked]
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>>>>
>      >      >      >     <mailto:[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>
>      >      >      >      >      >
>     <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>>>>>
>      >      >      >      >      > or
>     ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>>>>
>      >      >      >      >
>      >      >      >      >   
>      >      >      >      >     BESS mailing list
>      >      >      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>
>      >      >      >      > https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>>>>>
>      >      >      >      >
>      >      >      >
>      >      >
>      >
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Tue, 22 Mar 2022 17:22:39 +0530

Hi Joel,

Thanks for the side chat to explain your concerns and sharing here with the
WG and RTG ADs the text clarification required.

Section 3.1

s/  An unrecognized endpoint behavior MUST NOT be considered invalid
by the receiver.
/ An unrecognized endpoint behavior MUST NOT be considered invalid by the
receiver except for behaviors that involve the use of arguments (refer to
Section 3.2.1 for details on argument validation).

We will incorporate this in the next update for the ongoing IESG Evaluation
unless there are any concerns.

Thanks,
Ketan

On Mon, Mar 21, 2022 at 4:46 PM Joel M. Halpern <[email-masked]> 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
> >      >      > KT> The draft does not say that the behavior is to be
> >     ignored. It
> >      >     says
> >      >      >     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
> >      >      >     3) If other information such as the use of the MPLS
> ESI or
> >      >     label (EVPN
> >      >      >     argument field of the resulting SID, then the Ingress
> >     PE acts
> >      >     on that
> >      >      >     describe when it needs to be understood, is for a use
> case
> >      >     that is not
> >      >      > KT> I am not sure that I understand the above two
> >     paragraphs very
> >      >     well.
> >      >      > the behavior is required at the ingress PE - to set the
> >     argument
> >      >     part of
> >      >      > arguments are not used, the SID can be used, as signaled,
> >     by the
> >      >     ingress
> >      >      >      >     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,
> >      >      >      > 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
> >      >      >      >     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
> >      >      >      > 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
> >      >      >      > 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
> >      >      >      >     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
> >      >      >      >      > ingress PE does not need to do anything
> specific
> >      >     with the
> >      >      >     choice
> >      >      >      >     of the
> >      >      >      >      > use of argument. Ingress PE does need to
> >     know & support
> >      >      >     the specific
> >      >      >      >     <[email-masked]
> >      >      >      >      >     It seems there is an implicit assumption
> >     that I
> >      >     would
> >      >      >     think
> >      >      >      >     it would be
> >      >      >      >      >     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,
> >      >      >      >      >     On 3/19/2022 11:32 PM,
> >      >      >      >      >      >          Title           : SRv6 BGP
> based
> >      >      >      >      >      >          Authors         : Gaurav
> Dawra
> >      >      >      >      >      >                            Clarence
> >      >      >      >      >      >                            Robert
> Raszuk
> >      >      >      >      >      >                            Bruno
> Decraene
> >      >      >      >      >      >                            Shunwan
> Zhuang
> >      >      >      >      >      >                            Jorge
> Rabadan
> >      >      >      >      >      >     RFC4364 "BGP/MPLS IP Virtual
> Private
> >      >     Networks
> >      >      >     (VPNs)"
> >      >      >      >     and RFC7432
> >      >      >      >      >      > The IETF datatracker status page for
> this
> >      >     draft is:
> >      >      >      >      >      >
> >      >      >      >
> <https://datatracker.ietf.org/doc/html/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
> >      >      >      >      >      > or