Re: [Idr] WG LC on draft-ietf-idr-bgp-flowspec-oid-10.txt [8/9 to 8/24/2019]

Christoph Loibl <c@tix.at> Mon, 26 August 2019 20:23 UTC

Return-Path: <c@tix.at>
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 0FE03120EDD for <idr@ietfa.amsl.com>; Mon, 26 Aug 2019 13:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 QX05ibh0zR7V for <idr@ietfa.amsl.com>; Mon, 26 Aug 2019 13:23:33 -0700 (PDT)
Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0373D12011C for <idr@ietf.org>; Mon, 26 Aug 2019 13:23:32 -0700 (PDT)
Received: from 80-110-113-122.cgn.dynamic.surfer.at ([80.110.113.122] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1i2LP9-0000fR-4H; Mon, 26 Aug 2019 22:15:56 +0200
From: Christoph Loibl <c@tix.at>
Message-Id: <D7CE3F73-A957-4617-9AB4-5EE3978D6EF0@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_689B4C85-C211-4F99-97C2-AA1FEF024220"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 26 Aug 2019 22:23:23 +0200
In-Reply-To: <B17A6910EEDD1F45980687268941550F4D8A3E60@MISOUT7MSGUSRCD.ITServices.sbc.com>
Cc: Susan Hares <shares@ndzh.com>, idr wg <idr@ietf.org>
To: "UTTARO, JAMES" <ju1738@att.com>
References: <01a501d54ec2$78335670$689a0350$@ndzh.com> <5A54FF55-68B9-454A-B176-0B1CF241EF40@tix.at> <B17A6910EEDD1F45980687268941550F4D8A3E60@MISOUT7MSGUSRCD.ITServices.sbc.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0>
Subject: Re: [Idr] WG LC on draft-ietf-idr-bgp-flowspec-oid-10.txt [8/9 to 8/24/2019]
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, 26 Aug 2019 20:23:38 -0000

James,

Sorry for being unclear. Let me put it this way:

From section 4 of flowspec-oid:

Step (a) of the validation procedure specified in [RFC5575bis <https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-08#ref-RFC5575bis>],
section 6 is redefined as follows:

 a.  One of the following conditions MUST hold true.

       *  The originator of the flow specification matches the
          originator of the best-match unicast route for the destination
          prefix embedded in the flow specification.

       *  The AS_PATH attribute of the flow specification does not
          contain AS_SET and/or AS_SEQUENCE segments.

When looking into RFC5575bis step (a) of the validation process is the following:

    a) A destination prefix component is embedded in the Flow
      Specification.

So this draft proposes to replace the requirement for a destination prefix embedded in the FS with your proposed text. While you leave step (b) of the validation process in RFC5575bis untouched:

    b) The originator of the Flow Specification matches the originator
      of the best-match unicast route for the destination prefix
      embedded in the Flow Specification.

This results in the following:

      a)  One of the following conditions MUST hold true.

       *  The originator of the flow specification matches the
          originator of the best-match unicast route for the destination
          prefix embedded in the flow specification.

       *  The AS_PATH attribute of the flow specification does not
          contain AS_SET and/or AS_SEQUENCE segments.


      b) The originator of the Flow Specification matches the originator
      of the best-match unicast route for the destination prefix
      embedded in the Flow Specification.

      c) There are no more specific unicast routes, when compared with
      the flow destination prefix, that has been received from a
      different neighboring AS than the best-match unicast route, which
      has been determined in rule b).
 
   Rule a) MAY be relaxed by configuration, permitting Flow
   Specifications that include no destination prefix component.  If such
   is the case, rules b) and c) are moot and MUST be disregarded.

 
I think that you actually want to replace rule (b) not rule (a) and you may want to read over the entire rfc5575bis validation procedure in order to see if the proposed changes (that were based on RFC5575 not rfc5575bis) still reflect the intended behaviour. 
  
Cheers Christoph

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at



> On 26.08.2019, at 15:44, UTTARO, JAMES <ju1738@att.com> wrote:
> 
> Christoph,
>  
>               The change to rfc5575 may be noted, are you suggesting a change to the method of modification of the validation rules in draft-ietf-bgp-flowpec-oid.txt ? Are you suggesting that the following addition to the validation procedure changes the behavior of the OID draft?
>  
> Thanks,
>               Jim Uttaro
>  
> P.S. I have attached the original rationale being the dissemination of FS updates from a centralized controller. View in slide mode for the animation…
>  
> A Flow Specification NLRI must be validated such that it is
>    considered feasible if and only if all of the below is true:
>  
>       a) A destination prefix component is embedded in the Flow
>       Specification.
>  
>       b) The originator of the Flow Specification matches the originator
>       of the best-match unicast route for the destination prefix
>       embedded in the Flow Specification.
>  
>       c) There are no more specific unicast routes, when compared with
>       the flow destination prefix, that has been received from a
>       different neighboring AS than the best-match unicast route, which
>       has been determined in rule b).
>  
>    Rule a) MAY be relaxed by configuration, permitting Flow
>    Specifications that include no destination prefix component.  If such
>    is the case, rules b) and c) are moot and MUST be disregarded.
>  
>  
>               
>  
> From: Idr <idr-bounces@ietf.org> On Behalf Of Christoph Loibl
> Sent: Monday, August 26, 2019 8:54 AM
> To: Susan Hares <shares@ndzh.com>
> Cc: idr wg <idr@ietf.org>
> Subject: Re: [Idr] WG LC on draft-ietf-idr-bgp-flowspec-oid-10.txt [8/9 to 8/24/2019]
>  
> Hi,
>  
> I think that a review of section 4 of this draft should be considered. At a very late stage we made changes to section 6 (validation procedure) of I-D.ietf-idr-rfc5575bis and I think that these changes should somehow be reflected in the flowspec-oid draft. 
>  
> For example the flowspec-oid redefines the validation procedure from section 6 of rfc5575bis the following way (which seems to be based on a older version of rfc5575bis):
>  
>  
> a.  One of the following conditions MUST hold true.
>  
>        *  The originator of the flow specification matches the
>           originator of the best-match unicast route for the destination
>           prefix embedded in the flow specification.
>  
>        *  The AS_PATH attribute of the flow specification does not
>           contain AS_SET and/or AS_SEQUENCE segments.
>  
>  
> While rfc5575bis has been modified in the meantime (to resolve the case where there is no destination-prefix embedded, this should somehow also be reflected in the flowspec-oid):
>  
> A Flow Specification NLRI must be validated such that it is
>    considered feasible if and only if all of the below is true:
>  
>       a) A destination prefix component is embedded in the Flow
>       Specification.
>  
>       b) The originator of the Flow Specification matches the originator
>       of the best-match unicast route for the destination prefix
>       embedded in the Flow Specification.
>  
>       c) There are no more specific unicast routes, when compared with
>       the flow destination prefix, that has been received from a
>       different neighboring AS than the best-match unicast route, which
>       has been determined in rule b).
>  
>    Rule a) MAY be relaxed by configuration, permitting Flow
>    Specifications that include no destination prefix component.  If such
>    is the case, rules b) and c) are moot and MUST be disregarded.
>  
>  
> Just for the record: Older versions of rfc5575bis had something very similar to the current version of flowspec-oid (ignoring the fact, that a FS NLRI may not have a destination-prefix embedded):
>  
> A Flow Specification NLRI must be validated such that it is
>    considered feasible if and only if:
>  
>       a) The originator of the Flow Specification matches the originator
>       of the best-match unicast route for the destination prefix
>       embedded in the Flow Specification.
>  
>       b) There are no more specific unicast routes, when compared with
>       the flow destination prefix, that has been received from a
>       different neighboring AS than the best-match unicast route, which
>       has been determined in step a).
>  
> Cheers Christoph
>  
> -- 
> Christoph Loibl
> c@tix.at <mailto:c@tix.at> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nextlayer.at&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=ylAzKv1c8UKkwohuI0aC6U5ERl-cN1sb-PVTboVAo0c&s=9OpnxK3SZYsQrbeo0Q3UtMdhNTcb1igCFz2H_5K29u0&e=>
>  
>  
> 
> 
> On 09.08.2019, at 16:55, Susan Hares <shares@ndzh.com <mailto:shares@ndzh.com>> wrote:
>  
> This begins a 2 week WG LC for draft-ietf-idr-bgp-flowspec-oid-10.txt [8/9
> to 8/24/2019] 
> 
> In your comments, please consider: 
> 
> 1) including "support" or "no support"
> 2) if this addition to RFC5575bis which allows a 
> route controller in an AS to originate Flow Specifications 
> is useful in deployments, and
> 3) if there are any technical issues or editorial 
> Issues that need to be adjusted in this specification 
> prior to publication.    
> 
> If you think adjustments need to be made in the text, 
> Indicate whether you think the adjustments are 
> Technical or editorial in nature. 
> 
> Cheerily, Sue 
> 
> 
> =============
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Inter-Domain Routing WG of the IETF.
> 
>        Title           : Revised Validation Procedure for BGP Flow
> Specifications
>        Authors         : James Uttaro
>                          Juan Alcaide
>                          Clarence Filsfils
>                          David Smith
>                          Pradosh Mohapatra
>               Filename        : draft-ietf-idr-bgp-flowspec-oid-10.txt
>               Pages           : 11
>               Date            : 2019-08-09
> 
> Abstract:
>   This document describes a modification to the validation procedure
>   defined in [RFC5575bis] for the dissemination of BGP Flow
>   Specifications.  [RFC5575bis] requires that the originator of the
>   Flow Specification matches the originator of the best-match unicast
>   route for the destination prefix embedded in the Flow Specification.
>   This allows only BGP speakers within the data forwarding path (such
>   as autonomous system border routers) to originate BGP Flow
>   Specifications.  Though it is possible to disseminate such Flow
>   Specifications directly from border routers, it may be operationally
>   cumbersome in an autonomous system with a large number of border
>   routers having complex BGP policies.  The modification proposed
>   herein enables Flow Specifications to be originated from a
>   centralized BGP route controller.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dbgp-2Dflowspec-2Doid_&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=ylAzKv1c8UKkwohuI0aC6U5ERl-cN1sb-PVTboVAo0c&s=kTmc6mhSAtqEx0qn_AGWeCoWJjlqhWsMHd08GgcJejc&e=>
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-10 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Didr-2Dbgp-2Dflowspec-2Doid-2D10&d=DwQFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=ylAzKv1c8UKkwohuI0aC6U5ERl-cN1sb-PVTboVAo0c&s=7uvdBQ711KNLMCe1u3rkVW0hqlh6nNd9p7LRJAIwOEM&e=>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-flowspec-oid-10 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Didr-2Dbgp-2Dflowspec-2Doid-2D10&d=DwQFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=ylAzKv1c8UKkwohuI0aC6U5ERl-cN1sb-PVTboVAo0c&s=uXmtTvmFP868DzDL7fg9vQY0SyWZR3udjbqad3eIa2k&e=>
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-flowspec-oid-10 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Didr-2Dbgp-2Dflowspec-2Doid-2D10&d=DwQFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=ylAzKv1c8UKkwohuI0aC6U5ERl-cN1sb-PVTboVAo0c&s=HfAGxq6F5PaV6PeXjDEEb0WAw7fa2uKgoD_RYXjyw3k&e=>
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwQFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=ylAzKv1c8UKkwohuI0aC6U5ERl-cN1sb-PVTboVAo0c&s=cg5bhk72IbGx_dhxIXRrHXDfBQpTihxaWc1bww1_c_o&e=>
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org <mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwQFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=ylAzKv1c8UKkwohuI0aC6U5ERl-cN1sb-PVTboVAo0c&s=D_WxjFn3Lm4rnJKWX36hklz3FZ5uDkW3NwEJXbheH14&e=>
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org <mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwQFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=ylAzKv1c8UKkwohuI0aC6U5ERl-cN1sb-PVTboVAo0c&s=D_WxjFn3Lm4rnJKWX36hklz3FZ5uDkW3NwEJXbheH14&e=>
>  
> <Flow-Spec-IETF.V1.pptx>