Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec
Adrian Farrel <adrian@olddog.co.uk> Wed, 04 March 2020 22:10 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDE63A0A3C; Wed, 4 Mar 2020 14:10:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 WAzbb3ecfHFU; Wed, 4 Mar 2020 14:10:12 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE6A3A0A3B; Wed, 4 Mar 2020 14:10:08 -0800 (PST)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 024MA63m014772; Wed, 4 Mar 2020 22:10:06 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 610222203A; Wed, 4 Mar 2020 22:10:06 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 4BCA722032; Wed, 4 Mar 2020 22:10:06 +0000 (GMT)
Received: from LAPTOPK7AS653V ([195.166.134.68]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 024MA58M013957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Mar 2020 22:10:05 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: pce@ietf.org
Cc: draft-ietf-pce-pcep-flowspec@ietf.org
References: <002101d5c415$6e064680$4a12d380$@olddog.co.uk> <CA+YzgTtOoGr=hnvhfs_kg83KCNGK7NRhS=TMBSFAzEqWPFaPQQ@mail.gmail.com> <07c501d5c7d3$9d4f3b60$d7edb220$@olddog.co.uk> <CA+YzgTs4FaovVDb-qJoMtc-sOGKEXOOVHrvSm2Z533p2SK5QCA@mail.gmail.com>
In-Reply-To: <CA+YzgTs4FaovVDb-qJoMtc-sOGKEXOOVHrvSm2Z533p2SK5QCA@mail.gmail.com>
Date: Wed, 04 Mar 2020 22:10:04 -0000
Organization: Old Dog Consulting
Message-ID: <078e01d5f271$a888edf0$f99ac9d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJY0TFaFNXT/jcA8ggyNpSwKvBeoQD+i/k3AgBJCbMBBZC4p6cS1jkA
Content-Language: en-gb
X-Originating-IP: 195.166.134.68
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25270.003
X-TM-AS-Result: No--17.969-10.0-31-10
X-imss-scan-details: No--17.969-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25270.003
X-TMASE-Result: 10--17.968600-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbBZe+w8sdYYaRiPTMMc/Mmn22R14ijZDjCi4 PQH9BFxL3bzvU6za9nD2hz44pynUHc7eljtqnG9WypiC33/79mcZskwWqoib3Jl8NETW6pKC42W uQY4IJB5c1v3k9wIeClAI8COXskjsRm/RfcFi/W9uh7qwx+D6T+dppbZRNp/I3FJULPGBSs67im J4LbFoqbNT8povc+7RvqW2U1BYUaJYtc4ZGS+dqYeAntdoMxBaMf5Pdi+0fLZjQ6o1zjtGHngWt 5DwssvIqfZdm7CFymy1NDW2ubtl8L4yBTF9emc57pujb8urdzYXnM0Bi4lHbi62hjZS0WoYw+eI 9NS3+fTD+icy+t1yfXphkJQHW2b9r9Xz9yCPONL805SSvoAPN0yQ5fRSh265T0IkL8xYhnilXLD Wgtdj/nSYMn8Dq9ZfKMc/LLFBYmzGeIUisV1G+bRStmZTxM8RmAQwMiIyxlSynk7TnYzMuiVCmT vDV2+nzfeXeyvceUyXjjGjP9WQ/mCXKwMj/6bWLGDmqzfHOB9RvgR0hkbG4L59Yrw3aQCHFF8DU jc6WqryKc8DS1523gJCJ4YVSNxRX0NNah2S8aVFeAr5guIYJgeCHewokHM/gOlK2zN496luzR9E VKQEHWvVibKxVuLZ0BkpfhIXys4TtsHJ1ZxlTDA2Ejh8jKICB4bXdj887A9QKAQSutQYXAKJH9O Qtm+kpJ0OYMrT0ynogpTfHZQQINuwvQXo1tqWiPwLZYCrvPb3+mUqDWUKyFrXKFPCbXO5nnoaR/ 3NxyzjMDx5N2jfwPbE9hfTw1ey84wlaZlBms6eAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1d934/rDAK3zhG2qikEpQGX8JRIRg3z5KfeAoui4jggoB2ZuxT8FgwaNijco0BdAa6vomCNY SdAV
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/ryeSc5ZCPEgTS9d-lan4MtwoKHM>
Subject: Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 22:10:14 -0000
Hi all, AFAICS, no one else has pitched in on this debate (so we can't really call it a debate). The easiest approach to keeping everyone (i.e., Pavan) happy is to take the following approach. > 2. Introduce a new flag in the FLOWSPEC object to explicitly indicate > that routes subject to LPM based forwarding MUST be installed. When this > flag is set, the FLOWSPEC object MUST carry only destination IPv4/IPv6 TLVs. The way I propose to handle it is to add a flag to the FLOWSPEC object with meaning: - clear: Use the Flow Filter TLV as a "flow specification" - set: Use the Flow Filter TLV to install a Longest Prefix Match route Define a new error "FlowSpec Error" : "Unsupported LPM Route" for use when the receiver does not support installing an LPM route for the Flow Filter TLV. An introductory sentence is also added saying: How an implementation decides how to filter traffic that matches a Flow Specification does not form part of this specification, but a flag is provided to indicate that the sender of a PCEP message that includes a Flow Specification is intended to be installed as a Longest Prefix Match route, or as a Flow Specification policy. I'll make the changes to the document, but note that we are well past WG last call. I hope that with the change we will be able to move ahead. Look out for the new revision. Best, Adrian -----Original Message----- From: Vishnu Pavan Beeram <vishnupavan@gmail.com> Sent: 13 January 2020 12:23 To: Adrian Farrel <adrian@olddog.co.uk> Cc: pce@ietf.org; draft-ietf-pce-pcep-flowspec@ietf.org Subject: Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec Adrian, Hi! Please see inline.. Regards, -Pavan On Fri, Jan 10, 2020 at 10:32 AM Adrian Farrel <adrian@olddog.co.uk> wrote: > Thanks Pavan, > > It’s good to have this documented clearly. > > Personally, I am amused/confused that **how** packets are intercepted for > classification (via a routing entry or via a data plane filter) is > important to the specification of this protocol. That is, the protocol says > “packets that match this flowspec MUST be placed on this LSP/path”. How an > implementation chooses to achieve that is, IMHO, not material to the > on-the-wire behaviour. That is, the packets will come in and will be placed > on the path, and the protocol instructions to achieve it do not need to > tell anyone how to achieve it. > > This is probably closest to your option 1. That is, an implementation may > choose to implement this however it wants. > > It would be wrong, also IMHO, to imply that an implementation must install > a data plane filter to handle PCEP flowspecs. That depends (of course) on > how you define a data plane filter. Existing (network element) implementations have config knobs that distinguish between adding a filter rule to steer traffic onto the path of a tunnel and installing a resolver route (LPM based forwarding). And like with most TE-Tunnel/TE-Policy specific config knobs, there seems to be a strong desire to let the Controller push/control these knobs. That is where my options 2 and 3 come in. > As to draft-ietf-pce-binding-label-sid, I fear I detect mission creep. > What was originally a simple association of a binding SID to a PCEP message > now also has an element of flowspec built in. I wonder whether that > document shouldn’t refer to draft-ietf-pce-flowspec if it wants to describe > what traffic to associate with a path. I'm not sure about mission creep, but the association of a binding type to a path does (already) describe the type of traffic steered onto the path. It results in the installation of a keyed entry in the forwarding plane with the action of steering the packets matching this entry to the selected path of the policy. Given the precedent, adding a couple of new binding types for destination prefixes seems appropriate. > Like you, I would like to hear more from the working group. Yeah, looking forward to see some opinions come in on this. > *From:* Vishnu Pavan Beeram <vishnupavan@gmail.com> > *Sent:* 10 January 2020 05:45 > *To:* Adrian Farrel <adrian@olddog.co.uk> > *Cc:* pce@ietf.org; draft-ietf-pce-pcep-flowspec@ietf.org > *Subject:* Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec > > Adrian, Hi! > > Much Thanks for starting this thread! There are multiple implementations > that support user-triggered installation/uninstallation of > destination-IPv4/IPv6 prefixes bound to a TE Path (installation of routes > subject to longest prefix match based forwarding) and it is important to > have this behavior covered in PCEP. > > I’m listing 3 options that were considered for addressing this item: > > 1. Add a new sub-section to Section 8 of > <draft-ietf-pce-pcep-flowspec> stating that an implementation receiving a > FLOWSPEC object that carries only destination IPv4/IPv6 TLVs may choose to > not install any data-plane filters and instead install routes that are > subject to longest prefix match (LPM) based forwarding. With this option, > the controller has no say in how the network element processes these > destination IPV4/IPv6 TLVs. > 2. Introduce a new flag in the FLOWSPEC object to explicitly indicate > that routes subject to LPM based forwarding MUST be installed. When this > flag is set, the FLOWSPEC object MUST carry only destination IPv4/IPv6 TLVs. > 3. Do not use the FLOWSPEC object at all for this; Use the > TE-PATH-BINDING TLV (introduced by draft-ietf-pce-binding-label-sid) > instead. This requires the addition of a couple of new Binding Types (BT) > to indicate destination-IPV4 and destination-IPv6 bindings. This also > requires us to add the ability to encode multiple Path Bindings (list) > in the same message and the ability to remove specific Path Bindings in a > given message. > > Based on some offline conversations with interested parties, there is a > strong need to have an explicit indication for this type of behavior (avoid > ambiguity with respect to filtering) -- so that makes Option 1 undesirable. > There is also a requirement to carry a mix of install and uninstall > destination prefixes associated with a path in the same message. The way > the FLOWSPEC object is currently defined (the R flag is specified per > FLOWSPEC object and not per TLV; parity with BGP), you would need one > object to carry the install prefixes and one more to carry the uninstall > prefixes. Given all this, there is some consensus among interested parties > to implement this behavior using the TE-PATH-BINDING TLV. Note that this > also means that draft-ietf-pce-pcep-flowspec can proceed as is. > > @WG -- Any thoughts? > > Regards, > > -Pavan > > On Sun, Jan 5, 2020 at 4:14 PM Adrian Farrel <adrian@olddog.co.uk> wrote: > > Hi WG, > > I received a couple of private emails about draft-ietf-pce-pcep-flowspec. > > Since they were private, I will try to be circumspect about who they were > from. > > The sender asked to have a flag attached to a flow specification that > indicates that it can be installed as a static route and thus not subject > to a firewall rule so the longest prefix matching can be performed to > manipulate route resolution for an LSP. > > The request also said that traditionally flow-specifications result in > firewall rules and those rules operate on packets before longest prefix > match. We want to install static routes, the equivalent of installing a > prefix for an LSP and if we treat a flowspec as a static route we can mess > things up like rule ordering and so on. > > The sender suggested that there are currently some draft(s) regarding this > behavior for BGP flowspec as well, but was not able to point me at them. > > I asked for some clarifications and got back: > > "What BGP-FS does is install data-plane filters. We handle that by > installing RIB entries (that's what BGP carries) into a RIB. Those entries > are transformed into firewall filters. What I am asking for is not > currently supported by BGP-flowspec. > > "What I am asking for is an indication that a flow-specification NOT be > transformed into a data-plane filter. In other words, installed as a > normal route where the route is subject to longest prefix match based > forwarding
- [Pce] A discussion point for draft-ietf-pce-pcep-… Adrian Farrel
- Re: [Pce] A discussion point for draft-ietf-pce-p… Vishnu Pavan Beeram
- Re: [Pce] A discussion point for draft-ietf-pce-p… Adrian Farrel
- Re: [Pce] A discussion point for draft-ietf-pce-p… Vishnu Pavan Beeram
- Re: [Pce] A discussion point for draft-ietf-pce-p… Adrian Farrel