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)" < [email protected]> wrote: > It ‘is' a community… just one used to indicate a > redirection/traffic-steering service… > > G/ > > From: <[email protected]> on behalf of Robert Raszuk <[email protected]> > Date: Tuesday 27 October 2015 at 10:37 > To: Gunter Van de Velde <[email protected]> > Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, > "[email protected]" <[email protected]>, Gunter Van De Velde < > [email protected]>, Lizhenbin <[email protected]>, > Haoweiguo <[email protected]> > 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)" < > [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
