Re: [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: New draft - Flowspec Path Redirect

"VAN DE VELDE, Gunter (Gunter)" <gunter.van_de_velde@alcatel-lucent.com> Tue, 27 October 2015 11:59 UTC

Return-Path: <gunter.van_de_velde@alcatel-lucent.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0B61A8771; Tue, 27 Oct 2015 04:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.61
X-Spam-Level:
X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 fKNiIRQX3lFH; Tue, 27 Oct 2015 04:59:06 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 8A1651A8772; Tue, 27 Oct 2015 04:59:05 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 2B6649BE93A48; Tue, 27 Oct 2015 11:59:00 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t9RBx1IN028684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Oct 2015 12:59:01 +0100
Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.12]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 27 Oct 2015 12:59:01 +0100
From: "VAN DE VELDE, Gunter (Gunter)" <gunter.van_de_velde@alcatel-lucent.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: New draft - Flowspec Path Redirect
Thread-Index: AQHREK7e6tBVCelG+EKkfRwiSy5uBw==
Date: Tue, 27 Oct 2015 11:59:00 +0000
Message-ID: <43AD2EFC-18AD-4397-81DB-E766BD9EB92E@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> <CA+b+ERntf_oZB+XwNpxDwKEt+_DjW4WahAZwArveu9uUDNpgKg@mail.gmail.com>
In-Reply-To: <CA+b+ERntf_oZB+XwNpxDwKEt+_DjW4WahAZwArveu9uUDNpgKg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_43AD2EFC18AD439781DBE766BD9EB92Ealcatellucentcom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/TdjgkfiHqnMWzSASPmyWQVHZRN8>
Cc: "spring@ietf.org" <spring@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: New draft - Flowspec Path Redirect
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 27 Oct 2015 11:59:13 -0000

Suggested in the draft:
The ‘C’ bit to copy the original traffic onto the redirect path.
There is a ‘TID’ field to allow nested or sequenced redirection service

To be discussed:
Type field: indication of additional Path_ID context if desired (I.e. Type1: redirect-to-IP; Type2: redirect-to-PATH_ID)

G/

From: <rraszuk@gmail.com<mailto:rraszuk@gmail.com>> on behalf of Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Date: Tuesday 27 October 2015 at 11:05
To: Gunter Van de Velde <gunter.van_de_velde@alcatel-lucent.com<mailto:gunter.van_de_velde@alcatel-lucent.com>>
Cc: "rtgwg@ietf.org<mailto:rtgwg@ietf.org>" <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>, Gunter Van De Velde <guntervandeveldecc@icloud.com<mailto:guntervandeveldecc@icloud.com>>, "idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:idr@ietf.org>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, Haoweiguo <haoweiguo@huawei.com<mailto:haoweiguo@huawei.com>>, Lizhenbin <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>
Subject: Re: [Idr] Regarding "Semantics Independent" Flowspec//答复: 答复: New draft - Flowspec Path Redirect


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<mailto: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<mailto:rraszuk@gmail.com>> on behalf of Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Date: Tuesday 27 October 2015 at 10:37
To: Gunter Van de Velde <gunter.van_de_velde@alcatel-lucent.com<mailto:gunter.van_de_velde@alcatel-lucent.com>>
Cc: "rtgwg@ietf.org<mailto:rtgwg@ietf.org>" <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, "idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:idr@ietf.org>>, Gunter Van De Velde <guntervandeveldecc@icloud.com<mailto:guntervandeveldecc@icloud.com>>, Lizhenbin <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>, Haoweiguo <haoweiguo@huawei.com<mailto: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<mailto: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<mailto:haoweiguo@huawei.com>>
Date: Tuesday 27 October 2015 at 03:24
To: Gunter Van de Velde <gunter.van_de_velde@alcatel-lucent.com<mailto:gunter.van_de_velde@alcatel-lucent.com>>, Lizhenbin <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>, Gunter Van De Velde <guntervandeveldecc@icloud.com<mailto:guntervandeveldecc@icloud.com>>, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: "idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:idr@ietf.org>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, "rtgwg@ietf.org<mailto:rtgwg@ietf.org>" <rtgwg@ietf.org<mailto: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<mailto:idr-bounces@ietf.org>] on behalf of VAN DE VELDE, Gunter (Gunter) [gunter.van_de_velde@alcatel-lucent.com<mailto: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<mailto:idr@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; rtgwg@ietf.org<mailto: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<mailto:lizhenbin@huawei.com>>
Date: Monday 26 October 2015 at 17:19
To: Gunter Van de Velde <gunter.van_de_velde@alcatel-lucent.com<mailto:gunter.van_de_velde@alcatel-lucent.com>>, Gunter Van De Velde <guntervandeveldecc@icloud.com<mailto:guntervandeveldecc@icloud.com>>, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: "idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:idr@ietf.org>>, "rtgwg@ietf.org<mailto:rtgwg@ietf.org>" <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto: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]
发送时间: 2015年9月28日 20:29
收件人: Lizhenbin; Gunter Van De Velde; Robert Raszuk
抄送: idr@ietf.org<mailto:idr@ietf.org>; pce@ietf.org<mailto: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<mailto:idr@ietf.org>", Gunter Van de Velde, "pce@ietf.org<mailto: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] 代表 Gunter Van De Velde
发送时间: 2015年9月23日 20:44
收件人: Robert Raszuk
抄送: idr@ietf.org<mailto: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<mailto: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<mailto: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<mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr
>

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