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

Gyan Mishra <hayabusagsm@gmail.com> Mon, 15 March 2021 23:49 UTC

Return-Path: <hayabusagsm@gmail.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 A617A3A133E for <idr@ietfa.amsl.com>; Mon, 15 Mar 2021 16:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wjN2krH9SGe2 for <idr@ietfa.amsl.com>; Mon, 15 Mar 2021 16:49:55 -0700 (PDT)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86CD3A133F for <idr@ietf.org>; Mon, 15 Mar 2021 16:49:55 -0700 (PDT)
Received: by mail-pf1-x432.google.com with SMTP id d21so1551195pfn.1 for <idr@ietf.org>; Mon, 15 Mar 2021 16:49:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IBSF703DS9xV+uBx1iPfCKOOQtN6D0r38JkraAWSztg=; b=eCemMZ6tRiBTWbPc8//XHuOd5Yir8zO/w1SSBEz0sxDhlYdty47n6IZavbUK202Jwg elF0H9kx6P/YiIDH8dtk3UbQqi/xSyQncs4HsNnR9t+T2vnAj/tPFBG7pHd/RfNYFPt3 PrjiFqVMkEnXrPeAsNtHRj2yVBdAVdfhRtGjeTyuCt3hUuDV9aAMJw1yMUTGNQoLRKwi 2rgvEDkNHxD0RxiIgPk92QQOspLMFs0DkAOxbjUwp7ie+PzgA1HotCYc6+IkFOvcCwcr btZ+qfTjodVlsla0lN+bwOaqBVyo0a5z6RUe2eMB7O/HOFTWU/ddvjr7jw7yOpFQjBlN zlvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IBSF703DS9xV+uBx1iPfCKOOQtN6D0r38JkraAWSztg=; b=iQ6rOa2/oNOQ9CW89ACgokZeywhwviWFeHXhpCuuP4uVNQkT9p4TvC21FoVAO1w+X0 xDrd72mCCBaM8+1tC0xYdosPaJEW4Nbl0cKMFPYVwVnzIjYawWi5HbvKZRS5qTF0ypVZ cDgVu1IlM77TggykJsrxTJh67IEAKdBgTT6o5o46Ov+t4iCAl1lC/4wGXELtejU+N+TA QpPF4skK9WTwr/gdAPeQzEw+3H0ZB1M86UEtZJh07g30BMK/Ej11ydbLMV2uh9Gmx3c7 4sG3VDUw8ubXFsAEv/WHAiBCLPO3FmdaFvMVGQCzF2JOYDeGa74FVzdBDd/yv7i6UsR7 WJGA==
X-Gm-Message-State: AOAM531xDAKlH5frr+M98PWI2st+puwIva9Z5p0g18/IOuM4lsU1eRnP HoMs/NWXNoz1OUvnyfokB4MdNtzJ/X5nt1rCwLU=
X-Google-Smtp-Source: ABdhPJzyCDbxSFXqatvvjw9LKwQ6RJ4+W42Q7mxVClBSFegq4PAJOigbp5wzwcc75uzxfKezlgfmWw7U+lv3wED9qWg=
X-Received: by 2002:aa7:9205:0:b029:1ec:8eab:7ca3 with SMTP id 5-20020aa792050000b02901ec8eab7ca3mr12591390pfo.20.1615852194031; Mon, 15 Mar 2021 16:49:54 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <MN2PR13MB408793C3C9D5398C13BA0DDAF26C9@MN2PR13MB4087.namprd13.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 15 Mar 2021 19:49:43 -0400
Message-ID: <CABNhwV1JwHv3pFczOTCb71t5dUbKnWfspF1zjNG6RdKOJB_9hg@mail.gmail.com>
To: Huaimo Chen <huaimo.chen@futurewei.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000008eb8205bd9be8d5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WZPpwv_IaQWktFyQXsUqon3qVzc>
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 23:49:59 -0000

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 <huaimo.chen@futurewei.com>
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>
> 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>
> > *Sent:* Friday, March 12, 2021 11:49 AM
> > *To:* Huaimo Chen <huaimo.chen@futurewei.com>
> > *Cc:* idr@ietf.org <idr@ietf.org>rg>; Lizhenbin <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>
> >> *Sent:* Friday, March 12, 2021 9:58 AM
> >> *To:* Huaimo Chen <huaimo.chen@futurewei.com>om>; Joel M. Halpern
> >> <jmh@joelhalpern.com>
> >> *Cc:* idr@ietf.org <idr@ietf.org>rg>; Lizhenbin <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
> 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