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

Joel Halpern Direct <jmh.direct@joelhalpern.com> Mon, 15 March 2021 15:54 UTC

Return-Path: <jmh.direct@joelhalpern.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3363A1484 for <idr@ietfa.amsl.com>; Mon, 15 Mar 2021 08:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quKbPn3lBTFE for <idr@ietfa.amsl.com>; Mon, 15 Mar 2021 08:54:09 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493073A1502 for <idr@ietf.org>; Mon, 15 Mar 2021 08:54:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Dzgvg1SvQz6G7nC; Mon, 15 Mar 2021 08:54:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1615823647; bh=JvYBaEbSJbq/HrBsg6QLvLGujeJDqWoxXAhykIMngfM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nGIj8w3G6JCBQKQPgQPhJL/B0hQmOEF9m+MCUrRj3JYwd2xSyVa27gYShXiomfybP s6ApRzuObLKme3BO00JEdGq3HXCSKHDS7Z8j3UuxitZoMFNnRsYkapr29k5Ebh9S5/ 0hhImj/NuALV/qABLjU8Rmp8+RR5iByphlxDEgUQ=
X-Quarantine-ID: <FP_mZ6UDkP3P>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4Dzgvf3cK0z6G7Jl; Mon, 15 Mar 2021 08:54:06 -0700 (PDT)
To: Huaimo Chen <huaimo.chen@futurewei.com>, Gyan Mishra <hayabusagsm@gmail.com>
Cc: "idr@ietf.org" <idr@ietf.org>
References: <MN2PR13MB40876899246382264C393D06F26F9@MN2PR13MB4087.namprd13.prod.outlook.com> <89430d8e-58c1-7854-27a5-b01a4cf9c43f@joelhalpern.com> <MN2PR13MB4087266ED6ECE72F5F281E86F26F9@MN2PR13MB4087.namprd13.prod.outlook.com> <41feb923-eeba-d7db-a048-1b335bf8f92b@joelhalpern.com> <MN2PR13MB40874FC93A03CCDE2A012ECBF26F9@MN2PR13MB4087.namprd13.prod.outlook.com> <ad81e08a-09ab-ef9a-3295-ab3cf58b740d@joelhalpern.com> <CABNhwV3PR_u2jG6Eo2uRwK0XRSemZJ006RdeuGG6_jyJnaZoAg@mail.gmail.com> <MN2PR13MB408793C3C9D5398C13BA0DDAF26C9@MN2PR13MB4087.namprd13.prod.outlook.com>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <be57d874-8e7e-1ff6-cb64-4660476f82ce@joelhalpern.com>
Date: Mon, 15 Mar 2021 11:54:05 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <MN2PR13MB408793C3C9D5398C13BA0DDAF26C9@MN2PR13MB4087.namprd13.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/HO3yw4w6Mi7AhT-2YZIG18IsW1U>
Subject: Re: [Idr] locator length : draft-li-idr-flowspec-srv6
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Mar 2021 15:54:12 -0000

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 <hayabusagsm@gmail.com>
> *Sent:* Saturday, March 13, 2021 1:27 AM
> *To:* Joel M. Halpern <jmh@joelhalpern.com>
> *Cc:* Huaimo Chen <huaimo.chen@futurewei.com>om>; idr@ietf.org <idr@ietf.org>
> *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 <jmh@joelhalpern.com 
> <mailto:jmh@joelhalpern.com>> 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 <jmh.direct@joelhalpern.com
>     <mailto:jmh.direct@joelhalpern.com>>
>      > *Sent:* Friday, March 12, 2021 11:49 AM
>      > *To:* Huaimo Chen <huaimo.chen@futurewei.com
>     <mailto:huaimo.chen@futurewei.com>>
>      > *Cc:* idr@ietf.org <mailto:idr@ietf.org> <idr@ietf.org
>     <mailto:idr@ietf.org>>; Lizhenbin <lizhenbin@huawei.com
>     <mailto:lizhenbin@huawei.com>>
>      > *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 <jmh.direct@joelhalpern.com
>     <mailto:jmh.direct@joelhalpern.com>>
>      >> *Sent:* Friday, March 12, 2021 9:58 AM
>      >> *To:* Huaimo Chen <huaimo.chen@futurewei.com
>     <mailto:huaimo.chen@futurewei.com>>; Joel M. Halpern
>      >> <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
>      >> *Cc:* idr@ietf.org <mailto:idr@ietf.org> <idr@ietf.org
>     <mailto:idr@ietf.org>>; Lizhenbin <lizhenbin@huawei.com
>     <mailto:lizhenbin@huawei.com>>
>      >> *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
>     Idr@ietf.org <mailto:Idr@ietf.org>
>     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
> 
>