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

[Joel Halpern Direct <[e-mail]>]

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:
> 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 <[e-mail]>
> *Sent:* Saturday, March 13, 2021 1:27 AM
> *To:* Joel M. Halpern <[e-mail]>
> *Cc:* Huaimo Chen <[e-mail]>; [e-mail] <[e-mail]>
> *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.
> 
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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.
> 
>     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:
>      > 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 <[e-mail]
>     <mailto:[e-mail]>>
>      > *Sent:* Friday, March 12, 2021 11:49 AM
>      > *To:* Huaimo Chen <[e-mail]
>     <mailto:[e-mail]>>
>      > *Cc:* [e-mail] <mailto:[e-mail]> <[e-mail]
>     <mailto:[e-mail]>>; Lizhenbin <[e-mail]
>     <mailto:[e-mail]>>
>      > *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 <[e-mail]
>     <mailto:[e-mail]>>
>      >> *Sent:* Friday, March 12, 2021 9:58 AM
>      >> *To:* Huaimo Chen <[e-mail]
>     <mailto:[e-mail]>>; Joel M. Halpern
>      >> <[e-mail] <mailto:[e-mail]>>
>      >> *Cc:* [e-mail] <mailto:[e-mail]> <[e-mail]
>     <mailto:[e-mail]>>; Lizhenbin <[e-mail]
>     <mailto:[e-mail]>>
>      >> *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
> 
>     _______________________________________________
>     Idr mailing list
>     [e-mail] <mailto:[e-mail]>
>     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=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
> 
>