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