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

From: "Susan Hares" <[email-masked]>
Date: Fri, 13 May 2016 06:46:58 -0400

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-interi
m-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-interi
m-2016-idr-5-1.pdf

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Fri, 13 May 2016 14:55:57 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Friday 13 May 2016 at 12:46
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.

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

========================

May 16, 2016
22:00 - 23:00 EDT

WebEx: https://ietf.webex.com/ietf/j.php?MTID=m9be481d19988dd1b545be6759aee267b

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

Chair Questions:

presentation at:
https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-interim-2016-idr-5-0.pdf

presentation at:
https://www.ietf.org/proceedings/interim/2016/05/16/idr/slides/slides-interim-2016-idr-5-1.pdf

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 13 May 2016 15:00:40 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of "Van De Velde, Gunter (Nokia - BE)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 13, 2016 at 10:55 AM
To: IDR List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.

Pre-liminar comments…..

Timeline info
==========

Kind Regards,
G/

Sue and John

========================

May 16, 2016
22:00 - 23:00 EDT

Questions for meeting:

Submitted by (Eric Wu)

Chair Questions:

presentation at:

presentation at:

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 13 May 2016 11:51:49 -0400

Acee:

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

Download recording link:

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:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Friday, May 13, 2016 11:01 AM
To: Van De Velde, Gunter (Nokia - BE); [email-masked]; John Scudder
Subject: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.

Hi John, 

Thanks,

Acee

From: Idr <[email-masked]> on behalf of "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Friday, May 13, 2016 at 10:55 AM
To: IDR List <[email-masked]>
Subject: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.

Pre-liminar comments…..

 

-------------

Timeline info

==========

 

 

==

 

==

 

==

 

==

 

==

Kind Regards,

G/

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Friday 13 May 2016 at 12:46
To: "[email-masked]" <[email-masked]>
Subject: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.

Sue and John 

========================

May 16, 2016

22:00 - 23:00 EDT

Join by phone

Access code: 649 235 411

Questions for meeting: 

Submitted by (Eric Wu)

Chair Questions: 

  a) Redirection to VRF, 

   and/or deployed?   

  Gunter Van De Velde

  21 minutes

presentation at: 

 

Eric Wu 

20 minutes 

Download recording link:

presentation at:

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 13 May 2016 18:37:30 +0000

Thanks Sue - I’ve watched it as well and would advise others to skip the first 7 minutes since it really doesn’t start until then.
Acee

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 13, 2016 at 11:51 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>, John Scudder <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.

Acee:

The location:

Sue

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

Hi John,

Thanks,
Acee

Pre-liminar comments…..

Timeline info
==========

Kind Regards,
G/

Sue and John

========================

May 16, 2016
22:00 - 23:00 EDT

Questions for meeting:

Submitted by (Eric Wu)

Chair Questions:

presentation at:

presentation at:

---

From: Zhuangshunwan <[email-masked]>
Date: Mon, 16 May 2016 07:20:59 +0000

Hi Gunter,

Thanks for your comments, Please see responses inline.

Best  Regards,
Shunwan & Eric.Wu

发件人: Idr [mailto:[email-masked]] 代表 Van De Velde, Gunter (Nokia - BE)
发送时间: 2016年5月13日 22:56
收件人: [email-masked]
主题: Re: [Idr] IDR interim on May 16th - webex, questions for meeting, and recordings.

Pre-liminar comments…..

Timeline info
==========

 [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
and discussed in IDR mailing list:
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.

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
and discussed in IDR mailing list:
https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.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.

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

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.

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.

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.

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.

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.

Kind Regards,
G/

Sue and John

========================

May 16, 2016
22:00 - 23:00 EDT

Questions for meeting:

Submitted by (Eric Wu)

Chair Questions:

presentation at:

presentation at:

---

From: Gunter Van De Velde <[email-masked]>
Date: Mon, 16 May 2016 12:14:13 +0200

Hi Shunwan, Eric, All,

Inline: GV>

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

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

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?

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

> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Gunter,
>  
> 发件人: Idr [mailto:[email-masked] <mailto:[email-masked]>] 代表 Van De Velde, Gunter (Nokia - BE)
> 发送时间: 2016年5月13日 22:56
> 收件人: [email-masked] <mailto:[email-masked]>
> 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>
> https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html <https://www.ietf.org/mail-archive/web/rtgwg/current/msg05195.html>
>  
> 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>
> 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>
>  
> From: Idr <[email-masked] <mailto:[email-masked]>> on behalf of Susan Hares <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> WebEx: https://ietf.webex.com/ietf/j.php?MTID=m9be481d19988dd1b545be6759aee267b <https://ietf.webex.com/ietf/j.php?MTID=m9be481d19988dd1b545be6759aee267b>
>   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>
>  
>  
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>