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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]>
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]>
> 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]>
> > *Sent:* Friday, March 12, 2021 11:49 AM
> > *To:* Huaimo Chen <[e-mail]>
> > *Cc:* [e-mail] <[e-mail]>; Lizhenbin <[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]>
> >> *Sent:* Friday, March 12, 2021 9:58 AM
> >> *To:* Huaimo Chen <[e-mail]>; Joel M. Halpern
> >> <[e-mail]>
> >> *Cc:* [e-mail] <[e-mail]>; Lizhenbin <[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]
> 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
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> *Silver Spring, MD
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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