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

[Robert Raszuk <[e-mail]>]

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)" <
[e-mail]> 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 <[e-mail]>
> Date: Tuesday 27 October 2015 at 03:24
> To: Gunter Van de Velde <[e-mail]>,
> Lizhenbin <[e-mail]>, Gunter Van De Velde <
> [e-mail]>, Robert Raszuk <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> 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 [[e-mail]] on behalf of VAN DE VELDE, Gunter
> (Gunter) [[e-mail]]
> *Sent:* Tuesday, October 27, 2015 0:47
> *To:* Lizhenbin; Gunter Van De Velde; Robert Raszuk
> *Cc:* [e-mail]; [e-mail]; [e-mail]
> *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 <[e-mail]>
> Date: Monday 26 October 2015 at 17:19
> To: Gunter Van de Velde <[e-mail]>, Gunter
> Van De Velde <[e-mail]>, Robert Raszuk <
> [e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> 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:[e-mail]
> <[e-mail]>]
> *发送时间:* 2015年9月28日 20:29
> *收件人:* Lizhenbin; Gunter Van De Velde; Robert Raszuk
> *抄送:* [e-mail]; [e-mail]
> *主题:* 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: *"[e-mail]", Gunter Van de Velde, "[e-mail]"
> *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:[e-mail] <[e-mail]>] *代表 *Gunter
> Van De Velde
> *发送时间:* 2015年9月23日 20:44
> *收件人:* Robert Raszuk
> *抄送:* [e-mail]; 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 <[e-mail]> 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)
> <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
> >
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>