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

["UTTARO, JAMES" <[e-mail]>]

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 <[e-mail]> On Behalf Of Christoph Loibl
Sent: Monday, August 26, 2019 8:54 AM
To: Susan Hares <[e-mail]>
Cc: idr wg <[e-mail]>
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
[e-mail]<mailto:[e-mail]> | 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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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=>