Subject: [Idr] locator length : draft-li-idr-flowspec-srv6

From: Huaimo Chen <[email-masked]>
Date: Fri, 12 Mar 2021 14:51:55 +0000

Hi Joel,

    Thank you very much for your comment during the IETF 110.

    Regarding to the lengths of locator(LOC)s and function(FUNCT)s in SIDs,
RFC8986 says that the locator length, is flexible, and an operator is free
to use the locator length of their choice. This seems indicating that the
operator can select the length for the locator. After their selection, the
the locator length is determined/fixed. This is illustrated by examples
in RFC8986.

    One example in the beginning of section 3.2 is as follows:
       For example, a network operator may:
          Assign block B::/48 to the SR domain
          Assign a unique B:N::/64 block to each SRv6-enabled node in the domain.
After this assignment, the length of the locators of the SIDs in the domain
is 64 bits.

    In the end of section 3.2, the text shows the Function fields of SIDs.
The length of function(FUNCT)s is 16 bits.

    When a SID is used in the domain, its locator length and function length
should have been determined.

    When an operator configures a SRv6 flow specification, involving
a SID or a group of SIDs, s/he should have known the locator length and
function length in the SID(s).

Best Regards,
Huaimo

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 12 Mar 2021 09:58:00 -0500

An operator can assign B::/48 and C::?46  for Locators.  Sure, it would 
usually be a single prefix with a single length.  But that is not required.

When one is examining the LOC, sure, you can use the value length to 
handle it.
But the way the mechanism is described, one could try to check just the 
FUNC bits, without matching the LOC.
First, that has the problem of needing exogenous information about the 
LOC length.

And it is actually worse than that.  Testing the FUNC bits of the 
destination field of an IP packet without checking the LOC bits is 
actually meaningless.  You don't even know if the DA is an SRv6 SID.

An yet further, there is no requirement that the encoding of the FUNC in 
different SIDs uses the same value representation.  The standardized 
values are for advertising in routing protocols, not for the packets.

Net: I don't think having the field identification works.

Yours,
Joel

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 12 Mar 2021 16:44:54 +0000

Hi Joel,

    Thanks much for your further comment.

    Just checking the FUNC bits should be limited. We will add some
text to state that in order to check the FUNC bits, the LOC needs to
be examined and matched first.

Best Regards,
Huaimo

________________________________
From: Joel Halpern Direct <[email-masked]>
Sent: Friday, March 12, 2021 9:58 AM
To: Huaimo Chen <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: [email-masked] <[email-masked]>; Lizhenbin <[email-masked]>
Subject: Re: locator length : draft-li-idr-flowspec-srv6

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 12 Mar 2021 11:49:21 -0500

Given that you have to check loc before func and check loc and func 
before arg, it would seem simpler to just use an address prefix.  Gets 
around all of the knowledge problems.

Note that a UI for creating flowspec filters can allow the user to 
specify it in all sorts of ways.  that does not mean we need to put all 
of them in the protocol when they are equivalent.

Yours,
Joel

On 3/12/2021 11:44 AM, Huaimo Chen wrote:
> ------------------------------------------------------------------------
> *From:* Joel Halpern Direct <[email-masked]>
> *Sent:* Friday, March 12, 2021 9:58 AM
> *To:* Huaimo Chen <[email-masked]>; Joel M. Halpern 
> <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>; Lizhenbin <[email-masked]>
> *Subject:* Re: locator length : draft-li-idr-flowspec-srv6

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 12 Mar 2021 20:19:30 +0000

Hi Joel,

    It seems that using loc, func and args in SID is simpler than using
address prefix of SID for SRv6 flow specification. For matching/filtering
on an IP destination address prefix, it seems that there is just bitwise
pattern matching. For matching/filtering on a SID (loc, func and args in SID),
there are a few operators such as eq, lt and gt (and combinations of them).

    For flow specification(s) to match a range of functions such as
from function value F1 to F1+1, to F1+n (where n > 1) in SID,
using IP address prefix seems need (n+1) flow specifications, each of
which is for one function value and would have two (type 1) components:
one component for matching the locator and the other for matching the
function value. Using loc and func in SID needs just one flow specification
having one (type TBD) component with three <op, value> pairs. The first pair
is for matching the locator and the other two for the range.

Best Regards,
Huaimo

________________________________
From: Joel Halpern Direct <[email-masked]>
Sent: Friday, March 12, 2021 11:49 AM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked] <[email-masked]>; Lizhenbin <[email-masked]>
Subject: Re: locator length : draft-li-idr-flowspec-srv6

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Mar 2021 15:29:01 -0500

I have to disagree with your basic premise.  At least for LOC and FUNC 
bits, less than and greater than are NOT meaningful comparisons.

Even for ARG bits, the only defined usage for the bits is such that 
comparisons other than equal to / not equal to are meaningless.

Yours,
Joel

On 3/12/2021 3:19 PM, Huaimo Chen wrote:
> *Sent:* Friday, March 12, 2021 11:49 AM
> *To:* Huaimo Chen <[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 13 Mar 2021 01:27:47 -0500

Huaimo

With SRv6 BGP Service overlay the egress PE signals the SRv6 Service SID in
SRv6 service TLV encoded in BGP prefix SID attribute with BGP overlay
service route for SRv6-BE /no SRH or egress PE colors overlay service route
with BGP color community for SRv6-TE w/ SRH.  The SRv6 source node
encapsulates the PE-CE customer payload in outer “MPLS topmost transport
label like” IPv6 header where the destination address is the SRv6 Service
SID provided by the egress PE.

The SRv6 L2 L3 VPN Services TLV is encoded in the BGP prefix SID attribute
identical to MPLS VPN service label and thus the VPN label is now encoded
into the func/arg SRv6 SID signaled by the egress PE and is fixed
throughout the closed SR domain.

SRv6 BGP Service overlay

https://tools.ietf.org/html/draft-ietf-bess-srv6-services-05

As SRv6 is reusing the IPv6 data plane with same L3 VPN overlay RFC 4364, I
don’t think any of the processes would change to carry BGP flow spec RFC
8955, as the BGP vpn overlay layer remains unchanged.

We are just swapping the underlay change from MPLS to IPv6 data plane.

Kind Regards

Gyan

On Fri, Mar 12, 2021 at 3:29 PM Joel M. Halpern <[email-masked]> wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 15 Mar 2021 14:26:03 +0000

Hi Joel,

    In the existing flow specification defined in RFC 8955 and 8956,
the operations lt (less than) and gt (greater than) are defined and
can be used on port.

    It seems that applying operations lt (less than) and gt (greater than)
on FUNC is similar to applying them on port.

Best Regards,
Huaimo

________________________________
From: Joel M. Halpern <[email-masked]>
Sent: Friday, March 12, 2021 3:29 PM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked] <[email-masked]>; Lizhenbin <[email-masked]>
Subject: Re: locator length : draft-li-idr-flowspec-srv6

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Mar 2021 10:35:32 -0400

Port ranges are a well-defined concepts.  Even address ranges are a well 
defined concepts.  There is no ordering for FUNC code points.  And the 
only defined meaning ARGs has a bit-oriented meaning where ranges would 
be at best coincidentally meaningfully.

Further, if the FUNC happen to have meaningful ranges, and are defined 
for a specific LOC, then one can define a pair of prefixes reflecting 
the edges of the range within the LOC.  SO a simple range representation 
in the "address" would cover that.  (After all, what is being tested is 
indeed the destiantion address field of a packet.)

If you really want a rule that tests a specific set of bits from the 
destination address, then the TLV for that kind of test needs to include 
the position of the bits, not just the value.  Declaring that the 
meaning of a FUNC test in a flowspec depends upon the configuraiton of 
the device creates interaction, complexity, and difficult to detect errors.

Yours,
Joel

On 3/15/2021 10:26 AM, Huaimo Chen wrote:
> *From:* Joel M. Halpern <[email-masked]>
> *Sent:* Friday, March 12, 2021 3:29 PM

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 15 Mar 2021 15:00:30 +0000

Hi Gyan,

    Thank you very much for your comments.

    RFC 8956 defines (Type 13) Flow Label component containing a list of
{numeric_op, value} pairs that are used to match the 20-bit Flow Label.
The operations on the label can be lt (less than) and gt (greater than).

    As you mentioned in your comments, MPLS VPN labels are encoded into
the func/arg of SRv6 SID. In this case, it seems that the operations
lt and gt on func/arg are the operations on label. Applying operations
lt and gt on func/arg (i.e., label) makes sense.

Best Regards,
Huaimo

________________________________
From: Gyan Mishra <[email-masked]>
Sent: Saturday, March 13, 2021 1:27 AM
To: Joel M. Halpern <[email-masked]>
Cc: Huaimo Chen <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Idr] locator length : draft-li-idr-flowspec-srv6

Huaimo

With SRv6 BGP Service overlay the egress PE signals the SRv6 Service SID in SRv6 service TLV encoded in BGP prefix SID attribute with BGP overlay service route for SRv6-BE /no SRH or egress PE colors overlay service route with BGP color community for SRv6-TE w/ SRH.  The SRv6 source node encapsulates the PE-CE customer payload in outer “MPLS topmost transport label like” IPv6 header where the destination address is the SRv6 Service SID provided by the egress PE.

The SRv6 L2 L3 VPN Services TLV is encoded in the BGP prefix SID attribute identical to MPLS VPN service label and thus the VPN label is now encoded into the func/arg SRv6 SID signaled by the egress PE and is fixed throughout the closed SR domain.

SRv6 BGP Service overlay

https://tools.ietf.org/html/draft-ietf-bess-srv6-services-05<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-bess-srv6-services-05&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823894640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cIFl1GwBr%2FkLm7j%2BI5XR8CuCwPkhcZEzsK8B8S8291Q%3D&reserved=0>

As SRv6 is reusing the IPv6 data plane with same L3 VPN overlay RFC 4364, I don’t think any of the processes would change to carry BGP flow spec RFC 8955, as the BGP vpn overlay layer remains unchanged.

Kind Regards

Gyan

On Fri, Mar 12, 2021 at 3:29 PM Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
I have to disagree with your basic premise.  At least for LOC and FUNC
bits, less than and greater than are NOT meaningful comparisons.

Yours,
Joel

On 3/12/2021 3:19 PM, Huaimo Chen wrote:
> *From:* Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
> *To:* Huaimo Chen <[email-masked]<mailto:[email-masked]>>
> *Cc:* [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>
>> *From:* Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
>> *To:* Huaimo Chen <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern
>> <[email-masked]<mailto:[email-masked]>>
>> *Cc:* [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823904595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=308PkYLf8wfcS9h%2BK07PUSuNMZuD%2B%2F877Xxxbo4hSDk%3D&reserved=0>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823904595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gqfjp5KslpJZe%2FM1vfBPfXeX81XslNzamG5SHfrDogQ%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 15 Mar 2021 11:54:05 -0400

Func / arg is not the label.  LOC+FUNC+ARG is the label.
While I doubt the utility, I understand that flowspec allows for 
applying such comparisons to the whole prefix.  I am not asking to get 
rid of that.  But there is no need to apply a range to just the FUNC, or 
worse just the ARG part.

Yours,
Joel

On 3/15/2021 11:00 AM, Huaimo Chen wrote:
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Saturday, March 13, 2021 1:27 AM
> *To:* Joel M. Halpern <[email-masked]>
> *Cc:* Huaimo Chen <[email-masked]>; [email-masked] <[email-masked]>
> *Subject:* Re: [Idr] locator length : draft-li-idr-flowspec-srv6
> Huaimo
> 
> With SRv6 BGP Service overlay the egress PE signals the SRv6 Service SID 
> in SRv6 service TLV encoded in BGP prefix SID attribute with BGP overlay 
> service route for SRv6-BE /no SRH or egress PE colors overlay service 
> route with BGP color community for SRv6-TE w/ SRH.  The SRv6 source node 
> label like” IPv6 header where the destination address is the SRv6 
> Service SID provided by the egress PE.
> 
> The SRv6 L2 L3 VPN Services TLV is encoded in the BGP prefix SID 
> attribute identical to MPLS VPN service label and thus the VPN label is 
> now encoded into the func/arg SRv6 SID signaled by the egress PE and is 
> fixed throughout the closed SR domain.
> 
> SRv6 BGP Service overlay
> 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-bess-srv6-services-05&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823894640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cIFl1GwBr%2FkLm7j%2BI5XR8CuCwPkhcZEzsK8B8S8291Q%3D&reserved=0>
> 
> As SRv6 is reusing the IPv6 data plane with same L3 VPN overlay RFC 
> 4364, I don’t think any of the processes would change to carry BGP flow 
> spec RFC 8955, as the BGP vpn overlay layer remains unchanged.
> 
>      > pattern matching. For matching/filtering on a SID (loc, func and
>     args in
>      > SID),
>      > *Cc:* [email-masked] <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>>; Lizhenbin <[email-masked]
>     <mailto:[email-masked]>>
>      >> *To:* Huaimo Chen <[email-masked]
>     <mailto:[email-masked]>>; Joel M. Halpern
>      >> <[email-masked] <mailto:[email-masked]>>
>      >> *Cc:* [email-masked] <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>>; Lizhenbin <[email-masked]
>     <mailto:[email-masked]>>
>      >>>      Regarding to the lengths of locator(LOC)s and
>     function(FUNCT)s in
>      >>> SIDs,
>      >>>            Assign a unique B:N::/64 block to each SRv6-enabled
>     node in
>      >>> the domain.
>      >>>      When a SID is used in the domain, its locator length and
>     function
>      >>> length
>     [email-masked] <mailto:[email-masked]>
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823904595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=308PkYLf8wfcS9h%2BK07PUSuNMZuD%2B%2F877Xxxbo4hSDk%3D&reserved=0>
> 
> -- 
> 
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823904595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gqfjp5KslpJZe%2FM1vfBPfXeX81XslNzamG5SHfrDogQ%3D&reserved=0>
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 15 Mar 2021 15:57:25 -0400

Hi Joel

Please see section 3 and 5 of SRv6 BGP overlay draft below.

t is my understanding that the 20 byte VPN service label MPLS  bottom of
stack label is encoded into the function portion or the SRv6 service SID.

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

Section 2

   o  SRv6 L3 Service TLV: This TLV encodes Service SID information for
      SRv6 based L3 services.  It corresponds to the equivalent
      functionality provided by an MPLS Label when received with a Layer
      3 service route as defined in [RFC4364
<https://datatracker.ietf.org/doc/html/rfc4364>] [RFC4659
<https://datatracker.ietf.org/doc/html/rfc4659>] [RFC8950
<https://datatracker.ietf.org/doc/html/rfc8950>]
      [I-D.ietf-bess-evpn-prefix-advertisement
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#ref-I-D.ietf-bess-evpn-prefix-advertisement>].
Some behaviors which
      MAY be encoded, but not limited to, are End.DX4, End.DT4, End.DX6,
      End.DT6, etc.

Section 6

5.1 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-5.1>.
IPv4 VPN Over SRv6 Core

   The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
   Over IPv6 Core defined in [RFC8950
<https://datatracker.ietf.org/doc/html/rfc8950>].

   Label field of IPv4-VPN NLRI is encoded as specified in [RFC8277
<https://datatracker.ietf.org/doc/html/rfc8277>]
   with the Label Value set to the Function part of the SRv6 SID when
   the Transposition Scheme of encoding (Section 4
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-4>)
is used and
   otherwise set to Implicit NULL.

   SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.  The
   behavior of the SRv6 SID is entirely up to the originator of the
   advertisement.  In practice, the behavior is End.DX4 or End.DT4.

5.2 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-5.2>.
IPv6 VPN Over SRv6 Core

   The MP_REACH_NLRI over SRv6 core is encoded according to IPv6 VPN
   over IPv6 Core is defined in [RFC4659
<https://datatracker.ietf.org/doc/html/rfc4659>].

   Label field of the IPv6-VPN NLRI is encoded as specified in
[RFC8277 <https://datatracker.ietf.org/doc/html/rfc8277>]
   with the Label Value set to the Function part of the SRv6 SID when
   the Transposition Scheme of encoding (Section 4
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-4>)
is used and
   otherwise set to Implicit NULL.

   SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.  The
   behavior of the SRv6 SID is entirely up to the originator of the
   advertisement.  In practice, the behavior is End.DX6 or End.DT6.

On Mon, Mar 15, 2021 at 11:54 AM Joel Halpern Direct <
[email-masked]> wrote:

> > <
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-bess-srv6-services-05&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823894640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cIFl1GwBr%2FkLm7j%2BI5XR8CuCwPkhcZEzsK8B8S8291Q%3D&reserved=0
> >
> >
> >     <mailto:[email-masked]>>
> >     <
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823904595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=308PkYLf8wfcS9h%2BK07PUSuNMZuD%2B%2F877Xxxbo4hSDk%3D&reserved=0
> >
> >
> > --
> >
> > <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823904595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gqfjp5KslpJZe%2FM1vfBPfXeX81XslNzamG5SHfrDogQ%3D&reserved=0
> >
> >
> > *Gyan Mishra*
> >
-- 

*Gyan Mishra*

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Mar 2021 16:04:56 -0400

I am pretty sure those quotes say exactly the opposite of what you describe.

The first one says that the FUNC field serves a function analogous to a 
VPN label.  Not that it encodes an MPLS label.

The others say that for advertising purposes, the FUNC field is 
represented in the label portion of the NLRI.  That does not suddenlty 
turn the FUNC into an MPLS label.

Yours,
Joel

PS: Even if it were an MPLS label, the ambiguity as to where it is 
located would still mean that having a separate type field for it would 
not be helpful.

On 3/15/2021 3:57 PM, Gyan Mishra wrote:
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06>
> 
> Section 2
> 
>        3 service route as defined in [RFC4364  <https://datatracker.ietf.org/doc/html/rfc4364>] [RFC4659  <https://datatracker.ietf.org/doc/html/rfc4659>] [RFC8950  <https://datatracker.ietf.org/doc/html/rfc8950>]
>        [I-D.ietf-bess-evpn-prefix-advertisement  <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#ref-I-D.ietf-bess-evpn-prefix-advertisement>].  Some behaviors which
>       5.1
>       <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-5.1>.
>       IPv4 VPN Over SRv6 Core
> 
> 
> 
>     Over IPv6 Core defined in [RFC8950  <https://datatracker.ietf.org/doc/html/rfc8950>].
> 
>     Label field of IPv4-VPN NLRI is encoded as specified in [RFC8277  <https://datatracker.ietf.org/doc/html/rfc8277>]
>     the Transposition Scheme of encoding (Section 4  <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-4>) is used and
>       5.2
>       <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-5.2>.
>       IPv6 VPN Over SRv6 Core
> 
> 
> 
>     over IPv6 Core is defined in [RFC4659  <https://datatracker.ietf.org/doc/html/rfc4659>].
> 
>     Label field of the IPv6-VPN NLRI is encoded as specified in [RFC8277  <https://datatracker.ietf.org/doc/html/rfc8277>]
>     the Transposition Scheme of encoding (Section 4  <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-4>) is used and
> On Mon, Mar 15, 2021 at 11:54 AM Joel Halpern Direct 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > *From:* Gyan Mishra <[email-masked]
>     <mailto:[email-masked]>>
>      > *To:* Joel M. Halpern <[email-masked]
>     <mailto:[email-masked]>>
>      > *Cc:* Huaimo Chen <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
>     <https://tools.ietf.org/html/draft-ietf-bess-srv6-services-05>
>      >
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-bess-srv6-services-05&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823894640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cIFl1GwBr%2FkLm7j%2BI5XR8CuCwPkhcZEzsK8B8S8291Q%3D&reserved=0
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-bess-srv6-services-05&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823894640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cIFl1GwBr%2FkLm7j%2BI5XR8CuCwPkhcZEzsK8B8S8291Q%3D&reserved=0>>
>      >
>      > On Fri, Mar 12, 2021 at 3:29 PM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >      > Hi Joel,
>      >      >
>      >      >      Thanks much for your further comment.
>      >      >
>      >      >      It seems that using loc, func and args in SID is simpler
>      >     than using
>      >      > address prefix of SID for SRv6 flow specification. For
>      >     matching/filtering
>      >      > on an IP destination address prefix, it seems that there
>     is just
>      >     bitwise
>      >      > pattern matching. For matching/filtering on a SID (loc,
>     func and
>      >     args in
>      >      > SID),
>      >      > there are a few operators such as eq, lt and gt (and
>     combinations
>      >     of them).
>      >      >
>      >      >      For flow specification(s) to match a range of
>     functions such as
>      >      > from function value F1 to F1+1, to F1+n (where n > 1) in SID,
>      >      > using IP address prefix seems need (n+1) flow
>     specifications, each of
>      >      > which is for one function value and would have two (type 1)
>      >     components:
>      >      > one component for matching the locator and the other for
>     matching the
>      >      > function value. Using loc and func in SID needs just one flow
>      >     specification
>      >      > having one (type TBD) component with three <op, value>
>     pairs. The
>      >     first pair
>      >      > is for matching the locator and the other two for the range.
>      >      >
>      >      > Best Regards,
>      >      > Huaimo
>      >      >
>      >      >
>      >   
>      >      > *From:* Joel Halpern Direct <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      > *Sent:* Friday, March 12, 2021 11:49 AM
>      >      > *To:* Huaimo Chen <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      > *Cc:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>; Lizhenbin
>     <[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > *Subject:* Re: locator length : draft-li-idr-flowspec-srv6
>      >      > Given that you have to check loc before func and check loc
>     and func
>      >      > before arg, it would seem simpler to just use an address
>     prefix.
>      >     Gets
>      >      > around all of the knowledge problems.
>      >      >
>      >      > Note that a UI for creating flowspec filters can allow the
>     user to
>      >      > specify it in all sorts of ways.  that does not mean we
>     need to
>      >     put all
>      >      > of them in the protocol when they are equivalent.
>      >      >
>      >      > Yours,
>      >      > Joel
>      >      >
>      >      > On 3/12/2021 11:44 AM, Huaimo Chen wrote:
>      >      >> Hi Joel,
>      >      >>
>      >      >>      Thanks much for your further comment.
>      >      >>
>      >      >>      Just checking the FUNC bits should be limited. We
>     will add some
>      >      >> text to state that in order to check the FUNC bits, the
>     LOC needs to
>      >      >> be examined and matched first.
>      >      >>
>      >      >> Best Regards,
>      >      >> Huaimo
>      >      >>
>      >      >>
>      >   
>      >      >> *From:* Joel Halpern Direct <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      >> *Sent:* Friday, March 12, 2021 9:58 AM
>      >      >> *To:* Huaimo Chen <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>; Joel M. Halpern
>      >      >> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >> *Cc:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>; Lizhenbin
>     <[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >> *Subject:* Re: locator length : draft-li-idr-flowspec-srv6
>      >      >> An operator can assign B::/48 and C::?46  for Locators. 
>     Sure,
>      >     it would
>      >      >> usually be a single prefix with a single length.  But that is
>      >     not required.
>      >      >>
>      >      >> When one is examining the LOC, sure, you can use the
>     value length to
>      >      >> handle it.
>      >      >> But the way the mechanism is described, one could try to
>     check
>      >     just the
>      >      >> FUNC bits, without matching the LOC.
>      >      >> First, that has the problem of needing exogenous information
>      >     about the
>      >      >> LOC length.
>      >      >>
>      >      >> And it is actually worse than that.  Testing the FUNC
>     bits of the
>      >      >> destination field of an IP packet without checking the
>     LOC bits is
>      >      >> actually meaningless.  You don't even know if the DA is
>     an SRv6 SID.
>      >      >>
>      >      >> An yet further, there is no requirement that the encoding
>     of the
>      >     FUNC in
>      >      >> different SIDs uses the same value representation.  The
>     standardized
>      >      >> values are for advertising in routing protocols, not for the
>      >     packets.
>      >      >>
>      >      >> Net: I don't think having the field identification works.
>      >      >>
>      >      >> Yours,
>      >      >> Joel
>      >      >>
>      >      >> On 3/12/2021 9:51 AM, Huaimo Chen wrote:
>      >      >>> Hi Joel,
>      >      >>>
>      >      >>>      Thank you very much for your comment during the
>     IETF 110.
>      >      >>>
>      >      >>>      Regarding to the lengths of locator(LOC)s and
>      >     function(FUNCT)s in
>      >      >>> SIDs,
>      >      >>> RFC8986 says that the locator length, is flexible, and an
>      >     operator is free
>      >      >>> to use the locator length of their choice. This seems
>      >     indicating that the
>      >      >>> operator can select the length for the locator. After their
>      >     selection, the
>      >      >>> the locator length is determined/fixed. This is
>     illustrated by
>      >     examples
>      >      >>> in RFC8986.
>      >      >>>
>      >      >>>      One example in the beginning of section 3.2 is as
>     follows:
>      >      >>>         For example, a network operator may:
>      >      >>>            Assign block B::/48 to the SR domain
>      >      >>>            Assign a unique B:N::/64 block to each
>     SRv6-enabled
>      >     node in
>      >      >>> the domain.
>      >      >>> After this assignment, the length of the locators of the
>     SIDs
>      >     in the domain
>      >      >>> is 64 bits.
>      >      >>>
>      >      >>>      In the end of section 3.2, the text shows the Function
>      >     fields of SIDs.
>      >      >>> The length of function(FUNCT)s is 16 bits.
>      >      >>>
>      >      >>>      When a SID is used in the domain, its locator
>     length and
>      >     function
>      >      >>> length
>      >      >>> should have been determined.
>      >      >>>
>      >      >>>      When an operator configures a SRv6 flow specification,
>      >     involving
>      >      >>> a SID or a group of SIDs, s/he should have known the locator
>      >     length and
>      >      >>> function length in the SID(s).
>      >      >>>
>      >      >>> Best Regards,
>      >      >>> Huaimo
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <https://www.ietf.org/mailman/listinfo/idr>
>      >   
>       <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823904595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=308PkYLf8wfcS9h%2BK07PUSuNMZuD%2B%2F877Xxxbo4hSDk%3D&reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823904595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=308PkYLf8wfcS9h%2BK07PUSuNMZuD%2B%2F877Xxxbo4hSDk%3D&reserved=0>>
>      >
>      > --
>      >
>      >
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823904595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gqfjp5KslpJZe%2FM1vfBPfXeX81XslNzamG5SHfrDogQ%3D&reserved=0
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cf35805d2e8784e5a795108d8e5e9251a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637512136823904595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gqfjp5KslpJZe%2FM1vfBPfXeX81XslNzamG5SHfrDogQ%3D&reserved=0>>
>      >
>      > *Gyan Mishra*
>      >

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 15 Mar 2021 19:43:29 -0400

Hi Joel

I believe we are saying the same thing.

> VPN label.  Not that it encodes an MPLS label.

     Gyan> Agreed

> turn the FUNC into an MPLS label.

    Gyan> I never said it turned it into an MPLS label.  Agreed.  The
function field represents the 20 byte VPN service label portion of  SAFI
128 VPN.  The control plane BGP NLRI carries SAFI 128 and MPLS data plane
label is carried in the label stack BOS bit set as service label.  So with
SRV6 the BGP control plane is as-is carried SAFI 128 with the data plane
portion VPN  data is now represented in the function field of the SRv6 SID.

> >        3 service route as defined in [RFC4364  <
> https://datatracker.ietf.org/doc/html/rfc4364>] [RFC4659  <
> https://datatracker.ietf.org/doc/html/rfc4659>] [RFC8950  <
> https://datatracker.ietf.org/doc/html/rfc8950>]
> >        [I-D.ietf-bess-evpn-prefix-advertisement  <
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#ref-I-D.ietf-bess-evpn-prefix-advertisement>].
> Some behaviors which
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-5.1
> >.
> >       IPv4 VPN Over SRv6 Core
> >
> >
> >
> >     Over IPv6 Core defined in [RFC8950  <
> https://datatracker.ietf.org/doc/html/rfc8950>].
> >
> >     Label field of IPv4-VPN NLRI is encoded as specified in [RFC8277  <
> https://datatracker.ietf.org/doc/html/rfc8277>]
> >     the Transposition Scheme of encoding (Section 4  <
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-4>)
> is used and
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-5.2
> >.
> >       IPv6 VPN Over SRv6 Core
> >
> >
> >
> >     over IPv6 Core is defined in [RFC4659  <
> https://datatracker.ietf.org/doc/html/rfc4659>].
> >
> >     the Transposition Scheme of encoding (Section 4  <
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#section-4>)
> is used and
> >      >      >      It seems that using loc, func and args in SID is
> simpler
> >      >     than using
> >      >      > on an IP destination address prefix, it seems that there
> >     is just
> >      >     bitwise
> >      >      > there are a few operators such as eq, lt and gt (and
> >     combinations
> >      >     of them).
> >      >      >
> >      >      > function value. Using loc and func in SID needs just one
> flow
> >      >     specification
> >      >      > having one (type TBD) component with three <op, value>
> >     pairs. The
> >      >     first pair
> >      >      > *From:* Joel Halpern Direct <[email-masked]
> >      >      > *Cc:* [email-masked] <mailto:[email-masked]>
> >      >      > before arg, it would seem simpler to just use an address
> >     prefix.
> >      >     Gets
> >      >      > specify it in all sorts of ways.  that does not mean we
> >     need to
> >      >     put all
> >      >      >> *From:* Joel Halpern Direct <[email-masked]
> >      >      >> *Cc:* [email-masked] <mailto:[email-masked]>
> >      >      >> An operator can assign B::/48 and C::?46  for Locators.
> >     Sure,
> >      >     it would
> >      >      >> usually be a single prefix with a single length.  But
> that is
> >      >     not required.
> >      >      >>
> >      >      >> But the way the mechanism is described, one could try to
> >     check
> >      >     just the
> >      >      >> First, that has the problem of needing exogenous
> information
> >      >     about the
> >      >      >> LOC length.
> >      >      >>
> >      >      >> An yet further, there is no requirement that the encoding
> >     of the
> >      >     FUNC in
> >      >      >> values are for advertising in routing protocols, not for
> the
> >      >     packets.
> >      >      >>
> >      >      >>> operator can select the length for the locator. After
> their
> >      >     selection, the
> >      >      >>> the locator length is determined/fixed. This is
> >     illustrated by
> >      >     examples
> >      >      >>> in RFC8986.
> >      >      >>>
> >      >      >>> After this assignment, the length of the locators of the
> >     SIDs
> >      >     in the domain
> >      >      >>> is 64 bits.
> >      >      >>>
> >      >      >>>      In the end of section 3.2, the text shows the
> Function
> >      >     fields of SIDs.
> >      >      >>>      When an operator configures a SRv6 flow
> specification,
> >      >     involving
> >      >      >>> a
> <https://www.google.com/maps/search/%3E%C2%A0+%C2%A0+%C2%A0+%3E%3E%3E+a?entry=gmail&source=g>
> SID or a group of SIDs, s/he should have known the locator
> >      >     length and
-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 15 Mar 2021 19:49:43 -0400

Hi Huaimo

I think it makes sense gt lt apply to function of SRV6 SID.

Kind Regards

Gyan

On Mon, Mar 15, 2021 at 11:00 AM Huaimo Chen <[email-masked]>
wrote:

> ------------------------------
> As SRv6 is reusing the IPv6 data plane with same L3 VPN overlay RFC 4364,
> I don’t think any of the processes would change to carry BGP flow spec RFC
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> *Silver Spring, MD
>
> --

*Gyan Mishra*