Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Gunter Van De Velde <guntervandeveldecc@icloud.com> Fri, 29 November 2019 10:13 UTC

Return-Path: <guntervandeveldecc@icloud.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 9BEC81200B1 for <idr@ietfa.amsl.com>; Fri, 29 Nov 2019 02:13:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.556
X-Spam-Level:
X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.141, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 lkL_09KLonxR for <idr@ietfa.amsl.com>; Fri, 29 Nov 2019 02:13:41 -0800 (PST)
Received: from mr85p00im-ztdg06021201.me.com (mr85p00im-ztdg06021201.me.com [17.58.23.189]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295F812090A for <idr@ietf.org>; Fri, 29 Nov 2019 02:13:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1575022419; bh=AVni6sleRxh2E3dt6b09XyaDizOC7ByE3I3hsTjA/60=; h=To:From:Subject:Date:Message-id:Content-Type; b=GUine9fCuy+NSwwSY8voyW1A6Iu4CRTlgfn/xTQgAbQ1bi81pUn1aQSiuZg1y5Rnq 5xjYeIbED8EnDX7Yke1/MNbPYO86WXd7rgt83xf9TzJ5szDff9lKNCntOwi+vww57z xaaWYCSjHkg5grwepsfjZlWpTffad3RDb1ODkAtV/jqK/Pkzei22u8MO/icGLcz2aG PKz1t2f45XRUF7exRqB4VNt28xD4FVyfuAcK8u+E0Im9unVwSP+fXB/WJ8xuXAMviT 1Vmhxo3T/jygYR21AQGr9p7lUGkgwuj8Me/iiDM0axWQp+IoIY1bbSfueSzob2NfFj dHxd4cgCBZ2TQ==
Received: from localhost (mr36p72im-hyfv09053001.me.com [10.44.94.142]) by mr85p00im-ztdg06021201.me.com (Postfix) with ESMTP id 8AAE51210D4; Fri, 29 Nov 2019 10:13:39 +0000 (UTC)
To: Robert Raszuk <robert@raszuk.net>
Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, "idr@ietf.org" <idr@ietf.org>, Sue Hares <shares@ndzh.com>
From: Gunter Van De Velde <guntervandeveldecc@icloud.com>
Date: Fri, 29 Nov 2019 10:13:39 -0000
X-Mailer: iCloud MailClient1921Hotfix3 MailServer1922B580.10000-master-0-c7cfd3b5b06e
Message-id: <e31b9ee1-6c36-48ff-85e7-adb6273d4cad@me.com>
Content-Type: multipart/alternative; boundary=Apple-Webmail-42--2cad2693-41d6-4665-8d59-4df09d4c2fe0
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-29_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1911290090
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZCtO5eWtRUgzac7hqp1N5BMs3Eo>
Subject: Re: [Idr] =?utf-8?q?WG_LC_draft-ietf-idr-flowspec-path-redirect-10?= =?utf-8?q?=2Etxt_=5B11/17/2019_to_12/2/2019=5D?=
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: Fri, 29 Nov 2019 10:13:42 -0000

Hi Robert,


While understanding your point, it does feel like opening a potential can of worms with respect to validation of all possible combinations humanly possible. Is the use-case for this capability solid enough that we need this complication? There seems nothing broken with keeping things simple. 


G/


Sent from iCloud

On November 29, 2019 at 10:34 AM, Robert Raszuk <robert@raszuk.net> wrote:


Gunter,


To your and Jeff's point regarding multiple redirect rules I have a bit different perspective. 


First let's observe that redirect could be realized in two forms (both are valid and used in practice): 


-A- redirect of the original flow 
-B- redirect of copy of the flow 


See while in -A- clearly one redirect must be used, in -B- on the other hand multiple redirects should be supported. One span, one security TAP, one TCP analyzer etc ... 


Your draft defines -A-. To add -B- all what is needed is just one bit flag. 


Would you consider it ? 


Cheers,
R.










On Fri, Nov 29, 2019 at 4:51 AM Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:

Hi Jeff,
 
Thanks for the feedback and suggestions.
 
See inline: GV>
 
-----Original Message-----
From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
Sent: Thursday, November 28, 2019 20:21
To: Sue Hares <shares@ndzh.com>
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
 
Sue,
 
 
 
> On Nov 18, 2019, at 12:41 AM, Susan Hares <shares@ndzh.com> wrote:
>
> This begins a 2 week WG Last call on draft-idr-flowspec-path-redirect-10.txt from [11/17/2019 to 12/2/2019].
> 
> You can obtain the draft at:
> 
> https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/
> 
> Consider in your review whether this draft:
> 
> 1)      Is compatible with draft-ietf-rfc5575bis-17.txt?
 
Yes.  (Close enough.)  The current version of the draft is implementable.
 
> 2)      Whether the draft is useful for deployments of flow specification
 
It can be useful.
 
> 3)      Is this technology ready for deployment?
> 4)      Is the write-up of this technology in draft-ietf-idr-flowspec-path-redirect clearly written and ready for publication?
 
Ready with minor issues, IMO:
 
Procedure-wise, there needs to be a bit more text covering cases about interactions with other traffic actions.  This was a known headache for similar drafts such as redirect-to-ip.  In particular, interaction with redirect-to-ip and redirect-to-vrf is needed.
 
GV> Section “6. Validation Procedures” gives input on this. We discussed this with you long ago and hence this text was added.
 
“
   While it MUST NOT happen, and is seen as invalid combination, it is
   possible from a semantics perspective to have multiple clashing
   redirect actions defined within a single flowspec rule.  For best and
   consistant compatibility with legacy implementations, the redirect
   functionality as documented by rfc5575bis MUST NOT be broken, and
   hence when a clash occurs, then rfc5575bis based redirect MUST take
   priority.
“
 
This means that redirect-to-VRF will take absolute priority to not break rfc5575bis behavior.
Having also redirect-to-ip will result in an invalid
 
 
The text "A single flowspec rule MUST NOT have more as one indirection-id per S-ID.  On a flowspec client the indirection-id with lowest S-ID MUST be imposed first for any given flowspec entry."  There's no procedure for what happens in error handling when you do have more than one of the same S-ID.  The text about the case for S-ID of 0 is also a bit ambiguous.  It feels like it's reading "there is no sequence", but what do you do when you then have ones that do?
 
GV> What about the following rewrite:
 
Original:
   The 'S-ID' field identifies a 4 bit Sequence ID field.  This field is
   used to provide a flowspec client an indication how and where to
   sequence the received indirection-ids.  The Sequence ID value 0
   indicates that Sequence ID field is NOT set and SHOULD be ignored.  A
   single flowspec rule MUST NOT have more as one indirection-id per
   S-ID.  On a flowspec client the indirection-id with lowest S-ID MUST
   be imposed first for any given flowspec entry.
 
New:
   The 'S-ID' field identifies a 4 bit Sequence ID field.  This field is
   used to provide a flowspec client an indication how and where to
   sequence the received indirection-ids.  The Sequence ID value 0
   indicates that Sequence ID field is NOT set and **all other sequence ID's**
   SHOULD be ignored.  A
   single flowspec rule MUST NOT have more as one indirection-id per
   S-ID.  On a flowspec client the indirection-id with lowest S-ID MUST
   be imposed first for any given flowspec entry.
 
GV> In section *6. Validation procedure" there is text to handle the error condition when the flowspec rule results in an invalid redirection, that prescribe what needs to happen when the “redirect to indirection-id” does not result in a valid redirection:
 
"
   While it MUST NOT happen, and is seen as invalid combination, it is
   possible from a semantics perspective to have multiple clashing
   redirect actions defined within a single flowspec rule.  For best and
   consistant compatibility with legacy implementations, the redirect
   functionality as documented by rfc5575bis MUST NOT be broken, and
   hence when a clash occurs, then rfc5575bis based redirect MUST take
   priority.  Additionally, if the "Redirect to indirection-id" does not
   result in a valid redirection, then the flowspec rule MUST be
   processed as if the "Redirect to indirection-id" community was not
   attached to the flowspec route.
"
 
GV> Is there more to add to this? (We could add a line to detail that “redirect-to-ip” is incompatible with “redirect to indirection-id” and result in invalid redirection rule, however to me that is already implied with enough detail in the text above)
 
A few IANA issues:
I see the type registry is currently registered with IANA (code point 0x09).  However, the sub-type registry is not established for some reason?
The ID-Type field likely needs its own IANA registry.  Values 1-5 are defined in this draft.
 
GV> Correct. There is a reason for this. When we asked IANA the code-points they informed me that once the document get to RFC the sub-type registry will be established by IANA.
 
The flags field (one octet) currently has 3 bits reserved.  In the past, we've not done a registry for such cases (c.f. graceful restart) until we need to start carving out those reserved bits for future extensions.  I leave it to the chairs' opinion whether we want this a priori or not.
 
G/
 
 
> 
> Thank you for considering this draft.
> 
> Cheerily, Susan Hares
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www..ietf.org/mailman/listinfo/idr
 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf..org/mailman/listinfo/idr
 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr