Re: [Idr] Roman Danyliw's No Objection on draft-ietf-idr-bgp-flowspec-oid-14: (with COMMENT)

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

Thanks Roman for your comments. I'll add them if already not mentioned.

But in particular:

"   While the
   proposed modification cannot be used for inter-domain coordination of
   traffic filtering, it greatly simplifies distribution of intra-domain
   traffic filtering policies within an autonomous system which has a
   large number of border routers having complex BGP policies."
"
We framed it as applicability because it contrast with the previous applicability description and aim of this draft.
First, we talk about intra-domain  traffic filtering and then about inter-traffic filtering. Do you have any particular suggestion?


"
Disabling the new condition above (b.2.2) is RECOMMENDED in networks where policy prohibits Flow Specification from originating inside the local domain or where configuration dictates that only the egress border routers (i.e. those that were also egress border routers for the best routes) will originating a Flow  Specification NLRI.
"

'policy' may be a bit ambiguous term, no? What about

"
Disabling the new condition above (b.2.2) is RECOMMENDED in networks where network policy prohibits Flow Specification from originating inside the local domain or where network configuration dictates that only the right egress border routers (i.e. those that were also egress border routers for the best routes) will be originating Flow  Specification NLRIs.
"

-J





-----Original Message-----
From: Roman Danyliw via Datatracker <[e-mail]> 
Sent: Monday, May 17, 2021 10:09 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Susan Hares <[e-mail]>; [e-mail]; [e-mail]
Subject: Roman Danyliw's No Objection on draft-ietf-idr-bgp-flowspec-oid-14: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-idr-bgp-flowspec-oid-14: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you Magnus Nystrom for the SECDIR review and for the subsequent updates by the authors.

** Section 2.  Editorial. s/same autonomous system than/same autonomous system as/

** Section 2.

   While the
   proposed modification cannot be used for inter-domain coordination of
   traffic filtering, it greatly simplifies distribution of intra-domain
   traffic filtering policies within an autonomous system which has a
   large number of border routers having complex BGP policies.

Should the above key detail be explicitly framed in an applicability statement?

** Section 4.1.  Editorial + normative guidance which frames the text on the intent of the designed network, not the operator “knowing something”.

OLD
Disabling the new condition above (b.2.2) could be a good practice
      if the operator knew with certainty that a Flow Specification
      would not be originated inside the local domain.

An additional
      case would be if it was known for a fact that only the right
      egress border routers (i.e. those that were also egress border
      routers for the best routes) were originating a Flow Specification
      NLRI.

NEW
Disabling the new condition above (b.2.2) is RECOMMENDED in networks where policy prohibits Flow Specification from originating inside the local domain or where configuration dictates that only the egress border routers (i.e. those that were also egress border routers for the best routes) will originating a Flow  Specification NLRI.