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]] 发送时间: 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]<mailto:[email protected]>", Gunter Van de Velde, "[email protected]<mailto:[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]] 代表 Gunter Van De Velde 发送时间: 2015年9月23日 20:44 收件人: Robert Raszuk 抄送: [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/idr
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
