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

["Van De Velde, Gunter (Nokia - BE)" <[e-mail]>]

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


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).

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

"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."


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)
* 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.

(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).


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


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.


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.

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
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

presentation at:
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
Download recording link:
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