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

Gyan Mishra <hayabusagsm@gmail.com> Sat, 13 March 2021 06:28 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 935C73A0E11 for <idr@ietfa.amsl.com>; Fri, 12 Mar 2021 22:28:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ou6DR4mSdyQ1 for <idr@ietfa.amsl.com>; Fri, 12 Mar 2021 22:27:59 -0800 (PST)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 4CB4E3A0E10 for <idr@ietf.org>; Fri, 12 Mar 2021 22:27:59 -0800 (PST)
Received: by mail-pj1-x1029.google.com with SMTP id q2-20020a17090a2e02b02900bee668844dso11770555pjd.3 for <idr@ietf.org>; Fri, 12 Mar 2021 22:27:59 -0800 (PST)
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=O6f9A5TNUuejzXLz3vFBunXJrDJcLRcBt52pDt3Na68=; b=eZJGFpEjve22kh5+lE3p1qkwNeXnqoyIY+/6I242szbaqH2nBgQ7Ztiqs3xlSACBGv AtLeCmd8aXzJq3RC6Mfm/TTR14SNZXvHIpE0pxouh3cOWX9Py0VoevNbDVoBrhvzFs5T ZvvveVG7fEKhnrIaMW8eCDWUZFTi8f0ah7v7m/QOQBAqOKTCXo32k5rr2xPQDjOSdCGV 710noi/qPKX2DMLoxobXFxan9p2cZ5+9mgFGVZ0s7GOzgpmbtkOtbh1HQtO+dZXZXFXT Bvn7cDvE0xaZicaWAGLjaLHjeDDzVDql824NIDv755vMaD3CQS9Q7xhily+hcJ8FCHyk +fLA==
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=O6f9A5TNUuejzXLz3vFBunXJrDJcLRcBt52pDt3Na68=; b=oruktbd5nrS69IxYCjBi5QiJWbivvqgcdrkX6P0QJei72tRkMfodCdln0cW7xnqCmK fGehs0ZkBlLXTEznk3SS11HAY2m7emadxb6ttVIWkdJGUPzBKJur3G/dyYz2gLkCgGHx 1fm1os3lhbUV6QbT+RlHCkQ1135/YxqAg1T+JS5+YwoaE2GeDnZglOvod9I1SzxoaZhj K99zSFsOt0BNW4brhwSh9Jq1zB+KltVVBhEUldzVDHRamEYKpgoFuFdoZH5pEomzi28j JWK4LiZNFjmXqzZ57gpQFyy2ynYL3K4wV9iJpqxsA2gC82ia5FaEjn1EfWHAGU7wrPe3 Cxvg==
X-Gm-Message-State: AOAM533EYjQByFWZfu7Pkd+4UZPgTgC0FlV+jcXAM+G6urnCsVWW5QI7 soa2Zgadhw759/wRELjpY463nQ0LvV2Mowq1fw0=
X-Google-Smtp-Source: ABdhPJzc1l6juhPozq8xJg+OxvQONsvkLblMpKzpdFjLpah5itGDrcIZ6aL7yCiDJNuIz4TSSpVvFVmmpZK9C2/QI4w=
X-Received: by 2002:a17:90b:2358:: with SMTP id ms24mr2102351pjb.132.1615616877731; Fri, 12 Mar 2021 22:27:57 -0800 (PST)
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>
In-Reply-To: <ad81e08a-09ab-ef9a-3295-ab3cf58b740d@joelhalpern.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 13 Mar 2021 01:27:47 -0500
Message-ID: <CABNhwV3PR_u2jG6Eo2uRwK0XRSemZJ006RdeuGG6_jyJnaZoAg@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Huaimo Chen <huaimo.chen@futurewei.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000017231f05bd651ea3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/MaATu7jZRLu8Mno8Z7EeIZXkn5o>
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: Sat, 13 Mar 2021 06:28:02 -0000

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 <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>; 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>; Joel M. Halpern
> >> <jmh@joelhalpern.com>
> >> *Cc:* idr@ietf.org <idr@ietf.org>; 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
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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