Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.

[Gunter Van De Velde <[e-mail]>]

Hi Shunwan, Eric, All,

Inline: GV>

> Timeline info
> ==========
>  
> draft-vandevelde-idr-flowspec-path-redirect-00 created on 14 September 2015
> draft-vandevelde-idr-flowspec-path-redirect-01 created on 12 January 2016
> draft-vandevelde-idr-flowspec-path-redirect-02 created on 17 March 2016
>  
> draft-li-idr-flowspec-redirect-generalized-sid-00 created on 21 March 2016
>  
>  
>  [Reply 01] 
> The idea of draft-li-idr-flowspec-redirect-generalized-sid had initially been presented in the IDR Interim Meeting of 2015-10-26:
> https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/slides-interim-2015-idr-12-8.pdf <https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/slides-interim-2015-idr-12-8.pdf>
> and discussed in IDR mailing list:
> https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html <https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html>
>  

>  


GV>
The suggested references document justification discussions around draft-li-idr-mpls-path-programming-02. 
The reference indicates that draft-vandevelde can use the indirection extended community to redirect to a tunnel programmed by draft-li-idr-mpls-path-programming.  


> At Oct 26, 2015, draft-vandevelde-idr-flowspec-path-redirect-00 described the “semantics independent” solution, but we think it should simultaneously add “semantics dependent” solution. That happened before draft-vandevelde-idr-flowspec-path-redirect-01 which created on 12 January 2016. At that time, we don’t think that a separate document is immediately needed.
>  
> After draft-vandevelde-idr-flowspec-path-redirect-01 created, we notice that it did not integrate “semantics dependent” solution, but as per our Research and development team’s opinion, we need the “semantics dependent” Redirect Action solution.
>  
> Then “semantics dependent” Redirect to Generalized Segment ID Action documented as draft-li-idr-flowspec-redirect-generalized-sid. Coincidentally, at the same time, draft-vandevelde introduces “B” bit to map the value encoded in the global administrator field to a Binding Segment Identifier value.


GV>
The concept of draft-vandevelde to signal a flowspec client using a redirection identifier is copied in draft-li without even referencing any version at all of draft-vandevelde-idr-flowspec-path-redirect. Coincidence?

> * Concept of Indirection tables has been added (hence adding the capability of context/semantics signalling already since version -01)
> [Reply 04]
> Sorry, about “context/semantics signalling already since version -01”, maybe we missed the related description or did not understand it correctly, can you show us the text in version -01?
>  


GV>
Draft-vandevelde has a discussion around mapping tables, and has the extended community ‘ eserved' bits that can be used to signal semantics or tunnel mapping table, and hence the capability is available. This capability is used when we actual added redirection to SR binding SID.

>  
> Draft-vandevelde has indeed the potential to be used in such a manner. The intend of this slide at the time of usage was to show an extreme example of the flexiblity the technology offers. When for example using redirection to binding-SID (as documented in latest draft-vandevelde) then the local mapping table can be based around the signalled semantics.
> [Reply 08]
> So Draft-vandevelde planned to support two categories of the local mapping tables?
> 1) the local mapping table per device;
> 2) the local mapping table per service;
> We think that “setup the mapping tables per service type” is easier to implement.


GV>
This is an interesting discussion. 
draft-vandevelde has the capability to optionally couple semantics to a mapping table.
This capability is a powerful tool.  Because of this capability currently both (1) and (2) are possible with draft-vandevelde. 

in addition alternate creative categories could be i.e. : (3) a mapping table per flowspec controller or (4) a table per tunnel configuration method/controller.

draft-vandevelde can enforce semantic coupling or can permit freedom to an operational user… There are pro's and con’s for each, and i welcome the WG to 
provide guidance on the operational implications to complement draft-vandevelde… 

G/



> On 16 May 2016, at 09:20, Zhuangshunwan <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Hi Gunter,
>  
> Thanks for your comments, Please see responses inline.
>  
> Best  Regards,
> Shunwan & Eric.Wu
>  
> 发件人: Idr [mailto:[e-mail] <mailto:[e-mail]>] 代表 Van De Velde, Gunter (Nokia - BE)
> 发送时间: 2016年5月13日 22:56
> 收件人: [e-mail] <mailto:[e-mail]>
> 主题: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.
>  
> Pre-liminar comments…..
>  
> Before engaging with my feedback and addressing the discussion slides, i would like to thank both Sue and John for going through the effort and time to try to make the recordings as good as possible and investing non-trivial amounts of time to get the job done.
>  
> I would also like to thanks Eric Wu to go through the exercise of recording his presentation of the slides. I went through the same exercise and even though there were less operational issues to deal with during my recording, it is a non-trivial task to speak to a screen and not to an audience. 
>  
>  
> Comments: Working slides discussion of the 16 May 2016 Interim IDR meeting:
> -------------
>  
>  
> Timeline info
> ==========
>  
> draft-vandevelde-idr-flowspec-path-redirect-00 created on 14 September 2015
> draft-vandevelde-idr-flowspec-path-redirect-01 created on 12 January 2016
> draft-vandevelde-idr-flowspec-path-redirect-02 created on 17 March 2016
>  
> draft-li-idr-flowspec-redirect-generalized-sid-00 created on 21 March 2016
>  
>  
>  [Reply 01] 
> The idea of draft-li-idr-flowspec-redirect-generalized-sid had initially been presented in the IDR Interim Meeting of 2015-10-26:
> https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/slides-interim-2015-idr-12-8.pdf <https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/slides-interim-2015-idr-12-8.pdf>
> and discussed in IDR mailing list:
> https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html <https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html>
>  
> At Oct 26, 2015, draft-vandevelde-idr-flowspec-path-redirect-00 described the “semantics independent” solution, but we think it should simultaneously add “semantics dependent” solution. That happened before draft-vandevelde-idr-flowspec-path-redirect-01 which created on 12 January 2016. At that time, we don’t think that a separate document is immediately needed.
>  
> After draft-vandevelde-idr-flowspec-path-redirect-01 created, we notice that it did not integrate “semantics dependent” solution, but as per our Research and development team’s opinion, we need the “semantics dependent” Redirect Action solution.
>  
> Then “semantics dependent” Redirect to Generalized Segment ID Action documented as draft-li-idr-flowspec-redirect-generalized-sid. Coincidentally, at the same time, draft-vandevelde introduces “B” bit to map the value encoded in the global administrator field to a Binding Segment Identifier value.
>  
> General slide observations about draft-li-generalised-sid-00 (ref. discussion slide for 16 May 2016)
> ==========================================================
>  
> Draft-li documents a flowspec action using a new community (generalized-SID). The extended community provides a flowspec client information to make a local forwarding decision by means of a local mapping table. The two main components used by the flowspec client is: (1) an identifier and (2) semantics.
>  
> Draft-vandevelde documents a flowspec action using a new community (Indirection-ID). The extended community provides a flowspec client information to make a local forwarding decision by means of a local mapping table. The two main components used by the flowspec client is: (1) an identifier and (2) optionally semantics (Table semantics + Tunnel-ID).
>  
> draft-vandevelde-idr-flowspec-path-redirect-02 was created “before" draft-li-idr-flowspec-redirect-generalized-sid-00 and achieves the same functionality and more. (For example draft-vandevelde has the potential to signal 8192 types of semantic mapping tables while draft-li has 255, another example is the TID field which allows dynamic Next-Next-Hop constructs use for EPE DDoS redirection).
> [Reply 02]
> The idea of draft-li-idr-flowspec-redirect-generalized-sid had initially been presented in the IDR Interim Meeting of 2015-10-26: 
> https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/slides-interim-2015-idr-12-8.pdf <https://www.ietf.org/proceedings/interim/2015/10/26/idr/slides/slides-interim-2015-idr-12-8.pdf>
> and discussed in IDR mailing list:
> https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html <https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html>
>  
> During WG addoption-call 3/25 to 4/8 the following has been mentioned by Ignas: http://www.ietf.org/mail-archive/web/idr/current/msg15512.html <http://www.ietf.org/mail-archive/web/idr/current/msg15512.html>
>  
> "Draft-vandevelde can achieve all what draft-hao and draft-li can, and in a more flexible way. Having the ability to decouple redirection tunnel type from redirection action is both practical and extensible - the actual tunnel to be used is a local operational decision for each network element, it is not necessary signalled at the same time and by the same mechanism. Decoupling signalling and redirect parts aligns well to operational practices of using specific tools for specific tasks. Just that BGP could do that does not necesasry mean that it should be used as a best fit. From operational perspective there is no need to have multiple solutions that try to address the narrow problem space in similar yet incompatible ways. There should be one document for redirect, and draft-vandevelde is a good starting base for that."
> [Reply 03] 
> As we understand，Draft-vandevelde can’t achieve what draft-hao can，draft-hao specifies the specific tunnel from Flowspec Controller and the redirect tunnel information is encoded in BGP Path Attribute [TUNNELENCAPS][MPP] that is carried in the BGP flow-spec UPDATE.
> Comparison to draft-vandevelde, draft-hao will have more little modification to existing mechanisms, No need to do Mapping /Recursive Lookup.
>  
> If draft-vandevelde uses more bits to present the type of semantic information and use them as type value like draft-li does, not “Per Service Per Bit” as Binding Bit defines in version -02, and support to setup the mapping tables per service type, we think that the requirements of draft-li can be addressed.
>  
>  
> Detail view: slide observations draft-li-generalised-sid-00 discussion
> =========================================================
>  
> Slide 2 (of the draft-li presentation): History 
> ==
>  
> The slide forgets to mention that draft-vandevelde was enhanced and progressed based upon constructive WG feedback. Much feedback has been integrated between draft-vandevelde -00 to –02 BEFORE draft–li even existed. For example:
> * Use-case scenario’s were added
> * "Path-id" changed to "Indirection-id"
> * Concept of Indirection tables has been added (hence adding the capability of context/semantics signalling already since version -01)
> [Reply 04]
> Sorry, about “context/semantics signalling already since version -01”, maybe we missed the related description or did not understand it correctly, can you show us the text in version -01?
>  
> * Flowspec validation information is added
> * signalling of context/semantics is added by introducing Binding-SID context identifier as a first extension of Indirection-id extended community.
>  
> It is an incorrect assumption of no context awareness in draft-vandevelde. draft-vandevelde-idr-flowspec-path-redirect added context support before draft-li existed, and raises questions about new elements exposed with draft-li compared to draft-vandevelde.
> [Reply 05]
> Please refer to Reply 01.
>  
> (fwiw The semantic awareness of draft-vandevelde is mentioned and the webex recording of draft-li between recording time-stamps 11m30s to 13m30s)
>  
>  
> Slide 3 (of the draft-li presentation)
> ==
>  
> No new capability is explained on this slide in comparison with the draft-vandevelde.
> In draft-vandevelde the information found in the indirection-id is used on a flowspec client in a local mapping-table (indirection-id table) to find local forwarding information. The new flowspec extended community as documented by draft-vandevelde can provide already a flowspec client the required semantic/context information (example is the ‘B’ bit).
> [Reply 06]
> Also, please refer to Reply 01.
>  
> Slide 4 (of the draft-li presentation)
> ==
>  
> The goal of draft-li is to define a “semantics dependent” action.
> However, draft-vandevelde already allows that functionality before draft-li existed
> [Reply 07]
> Also, please refer to Reply 01.
>  
> Slide 5 (of the draft-li presentation)
> ==
>  
> Draft-vandevelde has indeed the potential to be used in such a manner. The intend of this slide at the time of usage was to show an extreme example of the flexiblity the technology offers. When for example using redirection to binding-SID (as documented in latest draft-vandevelde) then the local mapping table can be based around the signalled semantics.
> [Reply 08]
> So Draft-vandevelde planned to support two categories of the local mapping tables?
> 1) the local mapping table per device;
> 2) the local mapping table per service;
> We think that “setup the mapping tables per service type” is easier to implement.
>  
>  
> Slide 6 (of the draft-li presentation)
> ==
>  
> Draft-vandevelde has 13 bits available for types, hence the potential to support/signal 2^13 (=8192) types when using the field as scalar value (when comparing with a potential for 255 types using draft-li)
>  
> The claim made on slide6 that draft-vandevelde allows only 13 type of semantic information is wrong assumption.
> [Reply 09]
> Sure, if draft-vandevelde uses more bits to present the type of semantic information and use them as type value like draft-li does, not “Per Service Per Bit” as Binding Bit defines in draft-vandevelde  version -02.
>  
> At the time of writing, it was found useful to signal binding SID useful semantic … We decided to leave the remaining bits reserved/open for discussion on how to best use the field instead. 
> Maybe the WG feels it is best to use only a few bits for semantics and keep the remainder reserved for future use. 
>  
> Kind Regards,
> G/
>  
>  
>  
> From: Idr <[e-mail] <mailto:[e-mail]>> on behalf of Susan Hares <[e-mail] <mailto:[e-mail]>>
> Date: Friday 13 May 2016 at 12:46
> To: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.
>  
> The time of the interim is 22:00-23:00 EDT on May 16th.  
>  
> The interim will discuss the following two drafts in order to create a WG solution:
>  
> ·         draft-vandevelde-idr-flowspec-path-redirect, and
> ·         draft-li-idr-flowspec-redirect-generalized-sid
>  
> Some of the Questions that will be discuss are included below.  Please review the pre-recording presentations prior to the meeting.   The Chairs encourage discussion of these questions on the list before, during, and after the meeting. 
>  
> Sue and John 
>  
> ========================
>  
> Agenda for IDR Virtual Interim Meeting
>  
> May 16, 2016
> 22:00 - 23:00 EDT
>  
> WebEx: https://ietf.webex.com/ietf/j.php?MTID=m9be481d19988dd1b545be6759aee267b <https://ietf.webex.com/ietf/j.php?MTID=m9be481d19988dd1b545be6759aee267b>
> Meeting number:            649 235 411
> Meeting password:         Jg66d2pm
> Join by phone
> 1-877-668-4493 Call-in toll free number (US/Canada)
> 1-650-479-3208 Call-in toll number (US/Canada)
> Access code: 649 235 411
>  
> Questions for meeting:
>  
> Submitted by (Eric Wu)
> 1. Redirect-to-Specific-Tunnel with BGP Path Attribute [TUNNELENCAPS][MPP] and
>   Redirect-to-IID/GSID, Required by different use cases, can we have two docs in IDR In parallel?
>   [Comparison to Redirect-to-IID/GSID , draft-hao will have more little modification
>   to existing mechanisms, No need to do Mapping /Recursive Lookup.]
>  
> 2.  For IID/GSID, one mapping table for
>   all kinds of segments/forwarding-entities vs. one mapping table
>   per segments/forwarding-entities type, should we support both?
>  
> Chair Questions: 
>  
> 1) Does the WG feel we need the following for RFC5575bis (DDoS)
>   a) Redirection to VRF,
>   b) Redirection to Indirection to IP, and  
>   c) Redirection to Service (new)?
>   
> 2) If the WG desires redirection to Service routing, does the WG desire
> a) Next-Hop tunnel support? -
> b) Next-Hop TE Tunnel support?
>  c) Nested Tunnel support?
>  d) Next-Next Hop Tunnel Support?
>  e) Router localized Tunnel recursion?
>  f) Tunnel Encap Recursion:
>  
> 3) What pieces of the proposed solutions have been implemented
>    and/or deployed?  
>  
>  
> Presentations (prerecorded, please review prior to meeting):
> - draft-vandevelde-idr-flowspec-path-redirect
>   Gunter Van De Velde
>   21 minutes
>   https://ietf.webex.com/ietf/ldr.php?RCID=e01d62661085f660f470feddd9bf266f <https://ietf.webex.com/ietf/ldr.php?RCID=e01d62661085f660f470feddd9bf266f>
>  
> presentation at: 
> https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-interim-2016-idr-5-0.pdf <https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-interim-2016-idr-5-0.pdf>
>  
>  
> draft-li-idr-flowspec-redirect-generalized-sid
> Eric Wu 
> 20 minutes 
>  
> Streaming recording link:
> https://ietf.webex.com/ietf/ldr.php?RCID=c8615aa845801a1e4b79cb1708a04484 <https://ietf.webex.com/ietf/ldr.php?RCID=c8615aa845801a1e4b79cb1708a04484>
> Download recording link:
> https://ietf.webex.com/ietf/lsr.php?RCID=4bd504329727d2a811c9cb0c9bc713d8 <https://ietf.webex.com/ietf/lsr.php?RCID=4bd504329727d2a811c9cb0c9bc713d8>
>  
> presentation at: 
> https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-interim-2016-idr-5-1.pdf <https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-interim-2016-idr-5-1.pdf>
>  
> _______________________________________________
> Idr mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>