Re: [Idr] AD Review of draft-ietf-idr-bgp-flowspec-oid-12

["Juan Alcaide (jalcaide)" <[e-mail]>]

Alvaro,

Apologies. I sent out doc with changes but I forgot a few ones. I commented in the original review you sent (look at [JUAN] after your comment).
Let me know if it's clear and enough.

I can send you proposed complete document with extra changes if it helps.

-J

-----Original Message-----
From: Alvaro Retana <[e-mail]> 
Sent: Thursday, January 28, 2021 12:04 AM
To: [e-mail]
Cc: Susan Hares <[e-mail]>; [e-mail]; IDR List <[e-mail]>
Subject: AD Review of draft-ietf-idr-bgp-flowspec-oid-12

Dear authors:

Thank you for your work on this document.

In general, I think that this document is simple and straight forward.
However, I have some major concerns (see details inline) that should be cleared up before proceeding.

Thanks!

Alvaro.



[Lines from idnits.]

...
4	Updates: 5575bis (if approved)                                J. Alcaide

[major] s/5575bis/rfc8955/g


...
15     Abstract

17	   This document describes a modification to the validation procedure
18	   defined for the dissemination of BGP Flow Specifications.  The
19	   dissemination of BGP Flow Specifications requires that the originator
20	   of the Flow Specification matches the originator of the best-match
21	   unicast route for the destination prefix embedded in the Flow
22	   Specification.  This allows only BGP speakers within the data
23	   forwarding path (such as autonomous system border routers) to
24	   originate BGP Flow Specifications.  Though it is possible to
25	   disseminate such Flow Specifications directly from border routers, it
26	   may be operationally cumbersome in an autonomous system with a large
27	   number of border routers having complex BGP policies.  The
28	   modification proposed herein enables Flow Specifications to be
29	   originated from a centralized BGP route controller.

[] rfc8955 and origination from ASBRs

Specifically on that point, the "originator" as defined in rfc8955 is "reset" at the AS boundary.  Regardless of whether the Flow Specification was originally generated at the ASBR or a centralized route controller, the receiving eBGP speaker will consider its eBGP peer to be the originator.

You would see the problem internal to the originating AS, unless the controller also originates the routes internally.

The motivation as laid out in the Abstract is making assumptiona that are not explained, resulting in lack of accuracy.  Please reword.
Note that many times "less is more" -- perhaps focus the Abstract on what the draft is proposing: updating the validation rules for iBGP and route server scenarios.

[JUAN]: Already shown in doc changes. New abstract + added introduction section

31	   This document updates RFC5575bis.

[major] s/This document updates RFC5575bis./This document updates the validation procedure in rfc8955.

[JUAN]: Will update


...
81	1.  Requirements Language

83	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
84	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
85	   document are to be interpreted as described in RFC 2119 [RFC2119].

[major] Use the rfc8174 template!


[JUAN]: Already shown in doc changes

87	2.  Introduction

89	   [I-D.ietf-idr-rfc5575bis] defined a new BGP [RFC4271] capability that
90	   can be used to distribute traffic Flow Specifications amongst BGP
91	   speakers in support of traffic filtering.  The primary intention of
92	   [I-D.ietf-idr-rfc5575bis] is to enable downstream autonomous systems
93	   to signal traffic filtering policies to upstream autonomous systems.
94	   In this way, traffic is filtered closer to the source and the
95	   upstream autonomous system(s) avoid carrying the traffic to the
96	   downstream autonomous system only to be discarded.  [I-D.ietf-idr-
97	   rfc5575bis] also enables more granular traffic filtering based upon
98	   upper layer protocol information (e.g., protocol port numbers) as
99	   opposed to coarse IP destination prefix-based filtering.  Flow
100	   specification NLRIs received from a BGP peer are subject to validity
101	   checks before being considered feasible and subsequently installed
102	   within the respective Adj-RIB-In.

[]
OLD>
   [I-D.ietf-idr-rfc5575bis] defined a new BGP [RFC4271] capability that
   can be used to distribute traffic Flow Specifications amongst BGP
   speakers in support of traffic filtering.

NEW>
   [RFC8955] defines a BGP NLRI [RFC4271] that can be used to distribute
   traffic Flow Specifications amongst BGP speakers in support of traffic
   filtering.

[JUAN]: Will update

104	   The validation procedure defined within [I-D.ietf-idr-rfc5575bis]
105	   requires that the originator of the Flow Specification NLRI matches
106	   the originator of the best-match unicast route for the destination
107	   prefix embedded in the Flow Specification.  This allows only BGP
108	   speakers within the data forwarding path (such as autonomous system
109	   border routers) to originate BGP Flow Specification NLRIs.  Though it
110	   is possible to disseminate such Flow Specification NLRIs directly
111	   from border routers, it may be operationally cumbersome in an
112	   autonomous system with a large number of border routers having
113	   complex BGP policies.

[] See the related comment in the Abstract.

[JUAN]: I added an extra section in the introduction at this point. Is that enough, or is there something in the paragraph above that you would like to see changed?

115	   This document describes a modification to the [I-D.ietf-idr-
116	   rfc5575bis] validation procedure allowing Flow Specification NLRIs to
117	   be originated from a centralized BGP route controller within the
118	   local autonomous system that is not in the data forwarding path