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

"Susan Hares" <shares@ndzh.com> Fri, 13 May 2016 15:52 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE312D59D for <idr@ietfa.amsl.com>; Fri, 13 May 2016 08:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.739
X-Spam-Level: *
X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNwE3v38Ge_D for <idr@ietfa.amsl.com>; Fri, 13 May 2016 08:51:57 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B373B12D187 for <idr@ietf.org>; Fri, 13 May 2016 08:51:56 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238;
From: Susan Hares <shares@ndzh.com>
To: "'Acee Lindem (acee)'" <acee@cisco.com>
References: <008a01d1ad04$c63a77d0$52af6770$@ndzh.com> <9F087909-60F3-4F5C-8427-C0BD2A4ED9FF@alcatel-lucent.com> <D35B6388.60D9E%acee@cisco.com>
In-Reply-To: <D35B6388.60D9E%acee@cisco.com>
Date: Fri, 13 May 2016 11:51:49 -0400
Message-ID: <00b601d1ad2f$5cbbe160$1633a420$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01D1AD0D.D5B31B00"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL9VAfH3qNrgami4jswlczYdF2oYwJJl/SIAmaezPadOjQ/QA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/1Tiw_TBzj5FpWL4HkZRcxTjDX7U>
Cc: idr@ietf.org
Subject: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2016 15:52:00 -0000

Acee:

 

The link for Eric’s talk is the message you copies (see below) and I included here: 

 

Streaming recording link:

https://ietf.webex.com/ietf/ldr.php?RCID=c8615aa845801a1e4b79cb1708a04484

Download recording link:

https://ietf.webex.com/ietf/lsr.php?RCID=4bd504329727d2a811c9cb0c9bc713d8

 

The location: 

https://www.ietf.org/proceedings/interim/2016/05/16/idr/agenda/agenda-interim-2016-idr-5

 

on the Agenda has both links. 

 

Sue 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, May 13, 2016 11:01 AM
To: Van De Velde, Gunter (Nokia - BE); idr@ietf.org; John Scudder
Subject: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.

 

Hi John, 

 

I was able to find Gunter’s WebEx recording via a URL in one of the E-mails but neither recording link is on the meeting materials page and I’d like to watch Eric’s as well. 

 

https://www.ietf.org/proceedings/interim/2016/05/16/idr/proceedings.html

 

Thanks,

Acee

 

From: Idr <idr-bounces@ietf.org> on behalf of "Van De Velde, Gunter (Nokia - BE)" <gunter.van_de_velde@nokia.com>
Date: Friday, May 13, 2016 at 10:55 AM
To: IDR List <idr@ietf.org>
Subject: 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

 

 

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 <idr-bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
Date: Friday 13 May 2016 at 12:46
To: "idr@ietf.org" <idr@ietf.org>
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