Re: [spring] [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: New draft - Flowspec Path Redirect
Robert Raszuk <robert@raszuk.net> Tue, 27 October 2015 10:05 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 087E61A6F80; Tue, 27 Oct 2015 03:05:34 -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 3erViH6qoWU7; Tue, 27 Oct 2015 03:05:28 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (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 4DEDC1A6FAE; Tue, 27 Oct 2015 03:05:27 -0700 (PDT)
Received: by wicfx6 with SMTP id fx6so151588694wic.1; Tue, 27 Oct 2015 03:05:25 -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=ZYpudiUgtucHLyvG1tYWQ5jZTsRKXRG7UJ5NOjxp9Ag=; b=yVS2YvmJtVwhYrYVrr4iyOV8nYbCuMnwBG7NwSEmNKDueHucTZOU4VutA4pmn5cY1n peoqgjf4q801KmtlHY1SQxi8UEh/n7nfspkJPi8W7XwkcwcijpXL/UE4i0H62raNGDS+ 2p6YWXTNLxjUudX4srbxnS9gtxx/ks6GB6/lyUARx0xW5mVUj8hbuWQj9O3DY46c8jru foaq8ySGstxSpWWOJmTr8pdisZruLIKifbM/YGZ2O7iy6+muffEXQaPyxN1vCNM0l0bm 2FNNoLkDfv+Lo5OI0YKql1s4QxWn78b3cHZ1jtorsgOwQQR0vS+HK2YUS4qLhhuQ6Vnc T5og==
MIME-Version: 1.0
X-Received: by 10.180.90.175 with SMTP id bx15mr22604516wib.92.1445940325663; Tue, 27 Oct 2015 03:05:25 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.194.114.199 with HTTP; Tue, 27 Oct 2015 03:05:25 -0700 (PDT)
Received: by 10.194.114.199 with HTTP; Tue, 27 Oct 2015 03:05:25 -0700 (PDT)
In-Reply-To: <367D0ADA-E73B-4A7A-A678-5F9928F80407@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> <CA+b+ER=gXRDN9rswCc6n+jsN+-LyXgC=gG81NTpCh4ezD9WoAA@mail.gmail.com> <367D0ADA-E73B-4A7A-A678-5F9928F80407@alcatel-lucent.com>
Date: Tue, 27 Oct 2015 11:05:25 +0100
X-Google-Sender-Auth: m3TX7t3Q_v8basvLh_qmKuv-X04
Message-ID: <CA+b+ERntf_oZB+XwNpxDwKEt+_DjW4WahAZwArveu9uUDNpgKg@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="f46d043c7d807a4f4e0523133718"
Archived-At: <http://mailarchive.ietf.org/arch/msg/spring/G-HO5QNsFCjYqEzPUlUwc_2rNx0>
Cc: Gunter Van De Velde <guntervandeveldecc@icloud.com>, "spring@ietf.org" <spring@ietf.org>, "idr@ietf.org" <idr@ietf.org>, 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 10:05:34 -0000
My question was specifically why *new* one is needed to just work as a marker ? R. On Oct 27, 2015 10:44 AM, "VAN DE VELDE, Gunter (Gunter)" < gunter.van_de_velde@alcatel-lucent.com> wrote: > It ‘is' a community… just one used to indicate a > redirection/traffic-steering service… > > G/ > > From: <rraszuk@gmail.com> on behalf of Robert Raszuk <robert@raszuk.net> > Date: Tuesday 27 October 2015 at 10:37 > To: Gunter Van de Velde <gunter.van_de_velde@alcatel-lucent.com> > Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>, "spring@ietf.org" <spring@ietf.org>, > "idr@ietf.org" <idr@ietf.org>, Gunter Van De Velde < > guntervandeveldecc@icloud.com>, Lizhenbin <lizhenbin@huawei.com>, > Haoweiguo <haoweiguo@huawei.com> > Subject: Re: [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: > New draft - Flowspec Path Redirect > > 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)