Re: [spring] [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: New draft - Flowspec Path Redirect
Robert Raszuk <robert@raszuk.net> Tue, 27 October 2015 09:37 UTC
Return-Path: <rraszuk@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729DF1A6EE8; Tue, 27 Oct 2015 02:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.977
X-Spam-Level:
X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 I9QmwSGJaWe5; Tue, 27 Oct 2015 02:37:47 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95391A6EED; Tue, 27 Oct 2015 02:37:46 -0700 (PDT)
Received: by wijp11 with SMTP id p11so204377918wij.0; Tue, 27 Oct 2015 02:37:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1HpLgD3FN2PO7FrDRpfgwkinLP6ymNK6nlkzVO2f91o=; b=tVk/iHeICEWjtLb8IOgEMAXNBIOjTee2geQRoWgufFtwJ53D0XVIE5Gfb8TqpeV2rT 1DlRcDYCEHfGq0QwCwkhQv5lGI6DAV36X6HbV2sjivJbSmoan8r+rZC8dc0PzMxmJhtE UCXH+dOL/LvKFAML+UoSrxbqSpLJkLBoJNdy0qfnMFQFO7OBUlWkA4+1uXF6sPlZRi4+ 15NfnnR3FMeEu+bGso/6NYFi2fOBRW0wXoonFaEFq6IgSxY3xUkrSSP4YBIzY7dC6h1P Bf0jcTuGt/XlghCwEpKRy9h9vFt3VFimceyhlNL5Gmtbayf5Vp34wnS6SNFTeizM2y+y x5QQ==
MIME-Version: 1.0
X-Received: by 10.194.216.34 with SMTP id on2mr23165844wjc.109.1445938665417; Tue, 27 Oct 2015 02:37:45 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.194.114.199 with HTTP; Tue, 27 Oct 2015 02:37:44 -0700 (PDT)
Received: by 10.194.114.199 with HTTP; Tue, 27 Oct 2015 02:37:44 -0700 (PDT)
In-Reply-To: <B0749F3E-2C9D-464D-9603-6A9BB2227A13@alcatel-lucent.com>
References: <3A4033D3-CC7E-4CEB-9D9E-1AF549235893@alcatel-lucent.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA5C661@nkgeml506-mbx.china.huawei.com> <566380D5-9912-44C1-AF2C-E3E2F4205583@alcatel-lucent.com> <DD5FC8DE455C3348B94340C0AB5517334F8D370A@nkgeml501-mbs.china.huawei.com> <B0749F3E-2C9D-464D-9603-6A9BB2227A13@alcatel-lucent.com>
Date: Tue, 27 Oct 2015 10:37:44 +0100
X-Google-Sender-Auth: 6Fg-OtxEqZUmAPcl3e0m5zcRBEc
Message-ID: <CA+b+ER=gXRDN9rswCc6n+jsN+-LyXgC=gG81NTpCh4ezD9WoAA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: "VAN DE VELDE, Gunter (Gunter)" <gunter.van_de_velde@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="089e013d14c284f6b7052312d411"
Archived-At: <http://mailarchive.ietf.org/arch/msg/spring/VhXKtIT_dF2dwsPENP3DtoG_1aw>
Cc: "idr@ietf.org" <idr@ietf.org>, spring@ietf.org, Gunter Van De Velde <guntervandeveldecc@icloud.com>, Haoweiguo <haoweiguo@huawei.com>, Lizhenbin <lizhenbin@huawei.com>, rtgwg@ietf.org
Subject: Re: [spring] [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: New draft - Flowspec Path Redirect
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2015 09:37:53 -0000
Gunter, No one in BGP land will question that decoupling and indirection is a good thing. But why do you need new PATH_ID rather then just using community as a marker ? Be it regular, extended or wide ? Cheers, R. On Oct 27, 2015 10:01 AM, "VAN DE VELDE, Gunter (Gunter)" < gunter.van_de_velde@alcatel-lucent.com> wrote: > When configuring a PBR on a router using CLI you identify the > ‘interesting’ traffic and the ‘actions’ upon the interesting traffic. > > PBR does not do anything for tunnel-setup or signaling… I do not think > that Flowspec should be involved at all with set-up or > tunnel initiation as there are much better solutions to achieve that goal > in existence already. Flowspec can be used by a controller > to signal policies, and a next to traffic conditioning instructions a > redirect policy seems as a reasonable fit. > > Long story short: BGP Flowspec allows a controller to signal in a > decoupled fashion both flow conditioning (already > exists) and flow steering (PATH_ID) meta-data. The receiving router > consumes this meta-data and takes based upon that > meta-data localised decisions. Decoupling is a very powerful tool. > > G/ > > From: Haoweiguo <haoweiguo@huawei.com> > Date: Tuesday 27 October 2015 at 03:24 > To: Gunter Van de Velde <gunter.van_de_velde@alcatel-lucent.com>, > Lizhenbin <lizhenbin@huawei.com>, Gunter Van De Velde < > guntervandeveldecc@icloud.com>, Robert Raszuk <robert@raszuk.net> > Cc: "idr@ietf.org" <idr@ietf.org>, "spring@ietf.org" <spring@ietf.org>, " > rtgwg@ietf.org" <rtgwg@ietf.org> > Subject: RE: [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: > New draft - Flowspec Path Redirect > > Hi Gunter, > > Understood your design method is to just specify PATH_ID in flowspec > message, and let the routers do local recursive action to select a set of > specific tunnel(s), the tunnel and PATH_ID association should be configured > beforehand at each router. The BGP flowspec initiator doesn't need to > specify detail tunnel attributes, the flowspec message is tunnel semantic > agnostic. The router local decision is totally unrestrictive, the > validation and security seems to be hard to be controlled. > > In traditional BGP flowspec designing, BGP flowspec initiator specifies > detail match fields and actions, the routers only enforce the actions > without any flexibility for local decision. If using the traditional > method, you worry about the complexity to specify detail tunnel attributes. > > If the BGP flowspec initiator only cares about the redirect target IP > address and tunnel type like NVO3, the tunnel attribute only need to > include head-end information. The attribute can be described by draft-rosen-idr-tunnel-encaps-00, > we only need to extend the draft usage for flowspec application. > > If the BGP flowspec initiator cares about the redirect target IP address > and other QOS attributes such as BW, we can specify the additional > attribute using BGP to notify the router, then the router perform local > tunnel selection per the attribute. > > In summary, i think the router local decision should not be completely > unrestrictive, the BGP flowspec initiator should specify some constraint > tunnel attribute to restrict local tunnel selection. The most relaxing mode > is to only specify redirect target IP address. More strictly attribute > specification will strengthen the constraint for each router's local tunnel > selection. This method will faciliate the validation and security concern. > > Thanks, > > weiguo > > ------------------------------ > > *From:* Idr [idr-bounces@ietf.org] on behalf of VAN DE VELDE, Gunter > (Gunter) [gunter.van_de_velde@alcatel-lucent.com] > *Sent:* Tuesday, October 27, 2015 0:47 > *To:* Lizhenbin; Gunter Van De Velde; Robert Raszuk > *Cc:* idr@ietf.org; spring@ietf.org; rtgwg@ietf.org > *Subject:* Re: [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: > New draft - Flowspec Path Redirect > > Let me just copy the answer I sent to another email I just sent to IDR: > > <>start snip<> > Hi Robin, > > Thanks for your note. > > A tunnel is not always going over shortest path. Some tunnels are TE > tunnels and are deliberately not going over a shortest path. This is > something that draft-rosen-idr-tunnel-encaps-00 will not help to signal > because the tunnel-encap attribute indicates tunnel parameters used by the > tail-end. > > If a redirect tunnel represents a particular redirect/steering service > (better delay, less packet loss, non-SRLG, more BW, etc…) then it does > become rather complex for BGP as signalling technology because a tunnel > relationship is a unique between 'a headend' and ‘a tailed' device. It > seems better to leave tunnel-setup to dedicated tunnel-setup mechanisms > like PCEP, SR, etc…. > > The draft redirect-to-PATH_ID is providing the means to signal a > flow-based redirect/steering service, and have each recipient router > identify using local recursion for the PATH_IDs the corresponding > tunnels/redirect-info. This allows for tunnel setup complexity to be taken > away from BGP, while at the same time BGP is doing what it is very good at > doing: "It signals a policy” in reliable fashion. > > Kind Regards, > G/ > > <>send snip<> > > When looking at: draft-litkowski-idr-flowspec-interfaceset then find that > this is a signalling method to identify on which interfaces the rule needs > to be activated upon. It is orthogonal from Redirect-to-path. > > Segment Routing is a fine technology to built shortest Path and TE > tunnels. Traffic steering is much more then redirecting to a Segment ID. > > Looking at the above, I see little logic in your proposal Robin. > > G/ > > From: Lizhenbin <lizhenbin@huawei.com> > Date: Monday 26 October 2015 at 17:19 > To: Gunter Van de Velde <gunter.van_de_velde@alcatel-lucent.com>, Gunter > Van De Velde <guntervandeveldecc@icloud.com>, Robert Raszuk < > robert@raszuk.net> > Cc: "idr@ietf.org" <idr@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, " > spring@ietf.org" <spring@ietf.org> > Subject: Regarding "Semantics Independent" Flowspec//答复: 答复: [Idr] New > draft - Flowspec Path Redirect > > Hi Folks, > > I think now the drafts of BGP Flowspec for redirect to VRF/IP/Tunnel keeps > the traditional way to extend BGP Flowspec to redirect to an entity with > explicit meaning which has been defined clearly in the existing work. > > Now draft-vandevelde-idr-flowspec-path-redirect is to introduce the Path > ID which can represent many forwarding entities. > draft-litkowski-idr-flowspec-interfaceset is also to introduce the new > “group ID” concepts. > > There will be the problem how to define the path ID and group ID. In fact, > my early comments proposed the suggestion that we can reuse some work of > segment routing and generalize the concept of Segment, then it > > can provide a base for the abstracted view of different forwarding > entities. In order to explain the usage, I proposed the draft > draft-li-spring-segment-path-programming to try to explain the idea > clearly. Since now > > segment ID can be the indicator of interface, node, tunnel, if we do not > map segment ID to MPLS label or IPv6 address, it can be an identifier of > all kinds of forwarding entities in the control plane which can be used > outside. > > Please refer to the Please refer to “5. Usecases of Segment Path > Programming” of draft-li-spring-segment-path-programming: > > -- 5.3. Steering Traffic without Mapping Segment to Label: This is the > usecase to use segment ID to implement “redirect to IP/Link”. > > -- 5.4. Centralized Mapping Service to Tunnels: This is the usecase to > use segment ID to implement “redirect to tunnel”. > > If BGP Flowspec can carry multiple segment IDs which represent different > links of nodes, it can implement “redirect to interface group”. > > So I think if we can consolidate work of > draft-vandevelde-idr-flowspec-path-redirect/ > draft-litkowski-idr-flowspec-interfaceset/ > draft-li-spring-segment-path-programming to propose the draft of BGP > Flowspec “Redirect to Segment ID” > > to implement “Semantics Independent” Flowspec. The existing SRGB info > advertisement and SID allocation mechanism can be easily reused and > enhanced to provide the base instead of defining the new idea and > implementation of > > Path ID/Group ID. > > > > > > > > Best Regards, > > Zhenbin(Robin) > > > > > > *发件人:* VAN DE VELDE, Gunter (Gunter) [ > mailto:gunter.van_de_velde@alcatel-lucent.com > <gunter.van_de_velde@alcatel-lucent.com>] > *发送时间:* 2015年9月28日 20:29 > *收件人:* Lizhenbin; Gunter Van De Velde; Robert Raszuk > *抄送:* idr@ietf.org; pce@ietf.org > *主题:* Re: 答复: [Idr] New draft - Flowspec Path Redirect > > > > Dear Zhenbin, > > > > For (1.) I’ll compose some more text in a -01 version of the existing > draft to document Flowspec PATH–ID. I assumed that it was clear with text > already in the document, however, confusion seems to happen nevertheless. > > > > For (2.) the indirection by abstraction is the beauty of the idea and that > is why its offering a more flexible solution then other idea's around the > topic out there. Its an abstract forwarding indirection ID provided by BGP > flow spec. Existing technology (PCE, SR, RSVP, manual-config, > orchestration, etc…) can be used to create/signal/maintain/etc the > tunnel/LSP/redirect-next-hop per application/service. > > > > The proposal draft-vandevelde-idr-flowspec-path-redirect-00 > <https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-00> does > not provide a label or encap information but recipient uses localised > redirect information from existing and fine working technologies. > > > > Btw, your statement below that only one Path-ID can be signalled is wrong > and is to some degree documented in the existing draft. > > > > G/ > > > > > > > > *From: *Lizhenbin > *Date: *Monday 28 September 2015 13:16 > *To: *Gunter Van De Velde, Robert Raszuk > *Cc: *"idr@ietf.org", Gunter Van de Velde, "pce@ietf.org" > *Subject: *答复: [Idr] New draft - Flowspec Path Redirect > > > > Hi Gunter and Robert, > > We are also doing similar work. Regarding the draft, the major concern is > as follows: > > 1. What does the PATH_ID represent? Does it mean only tunnel/LSP or all > possible forwarding path including tunnel/LSP, interface, VRF, nexthop, etc? > > 2. How to allocate the PATH_ID for the forwarding path? > > We think the forwarding behavior for Flowspec is always actual forwarding > concepts including VRF, nexthop, etc. So we proposed ‘redirect to tunnel’ > in similar way. But for PATH_ID you proposed is another way to generalize > all possible forwarding path. It may be a new way to define forwarding > behavior for BGP Flowspec. > > > > Regarding redirecting tunnel, we proposed several drafts for your > reference: > > -- draft-hao-idr-flowspec-nvo3-00 > > -- draft-li-idr-mpls-path-programming-01 > > -- draft-li-spring-tunnel-segment-00 > > -- draft-chen-pce-pce-initiated-ip-tunnel-00 > > -- draft-li-pce-tunnel-segment-00 > > > > As Weiguo mentioned, the "redirect to Tunnel" for BGP Flowspec has been > described briefly in draft-hao-idr-flowspec-nvo3-00. We will split it into > two drafts: 1. draft-hao-idr-flowspec-nvo3-01; 2. one independent draft to > define the "redirect to tunnel" for BGP Flowspec. > > > > For "redirect to tunnel" for BGP flowspec, in fact there can be two types > of such behaviors: > > 1. Specify the tunnel type: > > For this behavior, we will reuse the IP tunnel types defined in > [draft-rosen-idr-tunnel-encaps-00] and the MPLS tunnel types defined in > [draft-li-idr-mpls-path-programming-01]. > > 2. Specify the specific tunnel: > > For MPLS TE tunnel, there can be multiple MPLS TE tunnels for a specific > destination. The tunnel type may be not enough. Then it is necessary to > specify the specific MPLS TE tunnel through Tunnel Identifier. [RFC3209] > defined the Tunnel Identifier for MPLS TE tunnel. PCE-initiated LSP adopted > the Tunnel Identifier for which tunnel ID can be allocated by PCE. > [draft-li-idr-mpls-path-programming-01] will try to reuse the tunnel > identifier and define it in the tunnel attribute which can be used for > "redirect to tunnel" in [draft-hao-idr-flowspec-nvo3-00]. > > For IP tunnel, there is always only one IP forwarding path for a specific > destination. So When define "redirect to specific IP tunnel" the nexthop > plus the tunnel type may be enough in the existing deployment. As the > development of IP tunnels, it may be popular to configure multiple IP > tunnels for the specific destination. For examples we can define multiple > MPLS-in-UDP tunnels for which the destination is same and the port number > can be different for the purpose of ECMP. In order to cope with such > development, [draft-chen-pce-pce-initiated-ip-tunnel-00] is proposed to > introduce the tunnel identifier for IP tunnels for which tunnel ID can also > be allocated by PCE as the MPLS TE tunnel. It may be also reused in the > tunnel attributes for the "redirect to tunnel". > > > > We think if it is only to think about "redirect to tunnel" for the BGP > Flowspec there has already been much existing work and it is better to > reuse them. > > > > In fact the existing work to specify a specific tunnel the tunnel > identifier is a combination with the ingress address/egress address and > tunnel ID. But for the draft > draft-vandevelde-idr-flowspec-path-redirect-00, PATH_ID can be only one > value to represent one tunnel. Recently we proposed the drafts > draft-li-spring-tunnel-segment-00/ draft-li-pce-tunnel-segment-00 in which > the segment ID/label can be allocated for a tunnel. This is also to use one > value to represent a tunnel. Now Segment Routing has defined many types > segments which can map to different forwarding path such as interface, > node, tunnel, etc. From my point of view, the work to define > Segment-ID/Label and PATH-ID for the forwarding path can be consolidated > and incorporated in the SRPING work. If we hope to define the generalized > concept, maybe we can define “Redirect to Segment” for the BGP Flowspec. In > [draft-li-idr-mpls-path-programming-01], we define the label combination > attributes to map the service to the MPLS forwarding path. Maybe it can be > enhanced to SID stack attribute to map to general forwarding path which can > be used for multiple BGP address family including BGP Flowspec. > > > > This is about our thinking on the "redirect to tunnel/path" work. Hope to > get your opinion on it. > > > > > > Best Regards, > > Zhenbin(Robin) > > > > > > > > > > > > > > *发件人:* Idr [mailto:idr-bounces@ietf.org <idr-bounces@ietf.org>] *代表 *Gunter > Van De Velde > *发送时间:* 2015年9月23日 20:44 > *收件人:* Robert Raszuk > *抄送:* idr@ietf.org; VAN DE VELDE, Gunter (Gunter) > *主题:* Re: [Idr] New draft - Flowspec Path Redirect > > > > Interresting question... I see few options to address this. (And fwiw, i > left this currently intentionally out the text to see if some ideas pop-up > to confirm or deny the ideas the authors had on this topic) > > The one which currently to me resonates most is to treat the path-id > similar as a traditional bgp next-hop address... Meaning, that if the > receiving router does't have a "valid" entry in the locallised path-id > table it treats flowspec rule as withdraw. > > Decision on what is considered "valid" is at first glance a local router > decision. > > If you have another proposal i would be happy to learn and see if it > resonates. > > Ciao, > G/ > > > > Sent using CloudMagic Email > <https://cloudmagic.com/k/d/mailapp?ct=pa&cv=7.3.5&pv=5.1.1&source=email_footer_2> > > On Wed, Sep 23, 2015 at 10:56 AM, Robert Raszuk <robert@raszuk.net> wrote: > > > > Hey Gunter, > > Let me ask you a question (which in fact also applies to redirect to > next hop draft). > > What is the expected system action when the redirect path is down > (assuming you have tools to detect it) or next hop you are redirecting > it to is unreachable ? > > I read your draft but other then definition of the encoding I was not > able to find answers for this. > > The original RFC5575 recommended redirect to local VRF which is just > as loopback normally up and within that VRF your orchestration can > redirect to next hop or path with whatever encapsulation you like. > > Here you (and redirect to next hop folks) are making a shortcut > however in both works I have not seen a proper discussion nor > definition of set of procedures which need to be executed upon your > redirect entity failure. > > I suggest both documents are updated with that before we proceed > further with both proposals. > > Cheers, > R. > > > > > On Wed, Sep 23, 2015 at 10:18 AM, VAN DE VELDE, Gunter (Gunter) > <gunter.van_de_velde@alcatel-lucent.com> wrote: > > Hi Folks, > > > > We have created a new draft to allow the capability to have Flowspec > signal > > a redirect to tunnel/LSP. > > > > > https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-00 > > > > The base principle is to use the indirection capability of BGP for path > > redirection. > > > > This proposal defines a new flowspec community to signal a redirect > > ‘path-id’. This path-id is is either a 128bit or 32bit value > > Assumed is that recipient router supporting path-id redirect have a > > localised path-id indexed table containing LSP/tunnel encapsulation > > information. > > Existing technology can be used to construct/create this table (LDP, SR, > > RSVP, manual-config, etc…) on a recipient router. The LSP/tunnel encap > table > > is indexed using 32 or 128 bit values. > > > > Flowspec path-id community is used to activate a redirect LSP/tunnel and > > provide by indirection the LSP/tunnel information for the flowspec > > identified traffic towards the LSP/tunnel. > > > > Benefits: > > > > no need for signalling labels or extra encap in BGP > > Each path-id indexed LSP/tunnel table is a localised construct > > existing technology is used to construct the path-id indexed localised > table > > Compatibility with technologies already using 32 or 128 bit identifiers > for > > paths and sessions > > Easy for flow spec to signal as it introduces no need to signal labels > etc… > > no conflicts with existing label exchange technologies > > > > Feedback welcome. > > > > G/ > > > > _______________________________________________ > > 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 > >
- [spring] Regarding "Semantics Independent" Flowsp… Lizhenbin
- Re: [spring] [Idr] Regarding "Semantics Independe… Robert Raszuk
- Re: [spring] [Idr] Regarding "Semantics Independe… Robert Raszuk
- Re: [spring] Regarding "Semantics Independent" Fl… VAN DE VELDE, Gunter (Gunter)
- Re: [spring] [Idr] Regarding "Semantics Independe… Haoweiguo
- Re: [spring] [Idr] Regarding "Semantics Independe… VAN DE VELDE, Gunter (Gunter)
- Re: [spring] [Idr] Regarding "Semantics Independe… VAN DE VELDE, Gunter (Gunter)
- Re: [spring] [Idr] Regarding "Semantics Independe… VAN DE VELDE, Gunter (Gunter)