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

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
>>
>>

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