IDR at IETF 92 
 Date: Tuesday March 24, 2015 15:20-17:20 
 
 Scribe: Steve Ultrich and Susan Hares 
1) Agenda Bashing/document Status [5 minutes] 

AS and Communities Discussions [30 minutes]
2) AS-Migration  [Wes George] [10 minutes] 
[draft-ietf-idr-as-migration]
http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/

• Questions posed by Wes:  
• Should we specify something that will cause all implementations to be out of specification? 
• Should we put justifications in the document? 
• Is this document vendor neutral? 
• Discussion: 
• John Scudder: Ido not want to specify something that will break existing implementations.
• Wes George: I already threaded the needle to try to be vendor netural 
• Eric Rosen: Put in much justification as possible.  For vendors, it is difficult to recall why something occurred unless it is document someplace. 
• Sidram: Did you consider standards track versus BCP?  
• Wes: It is does require adherence to this specification for the SIDR work to be possible.  There is a subsequent draft in SIDR. 
• John: Please send text to the mail list if you have suggested changes.  
• Wes: I will spin a draft with my changes. 
• Alvaro (incoming AD):  It read me like “go read this cisco web-site”.  My comment was to make it general since theweb site will change.  
• Wes: How many changes move this into a WG LC?  
• John: Upshot, there is going to be another spin of the document.  Let us know when you need additional help. 

3) BGP Wide Communities [10 minutes] 
draft-raszuk-wide-bgp-communities
http://tools.ietf.org/html/draft-raszuk-wide-bgp-communities-05
draft-raszuk-registered-wide-bgp-communities
http://tools.ietf.org/html/draft-raszuk-registered-wide-bgp-communities-00

• Discussion: 
• John: We will do an adoption call to the list
• Acee Linden: I looked at the registry with wide communities? 
• Robert: One draft is the encoding, and the second draft is the use cases.  If it is not enough, please let me know. 

4) BGP time  stamp: Updated [Stephane Litowski]  [5 minutes]  
http://datatracker.ietf.org/doc/draft-litkowski-idr-bgp-timestamp/ 

• Discussion: 
• Robert Raszuk: I like the work in general, but as a first reaction that I suggest the BGP path record draft to do both timestamp and record routes. 
• Stephane Litowski: I think we need to keep the timestamp as light a possible. I agree that we need a generatic container. 
• Robin Li (Huawei): When you reference the time stamp, what will you use for the clock.
• Stephane: We can use the timestamp from different types of clock.  
• Robin (Huawei): I think the synchronization the clock is key. 
• Stephane: We keep detailed information on the types of synchronization. 

5) draft-litkowski-idr-rtc-interas: Updated [Stephane Litowski] [5 minutes]
http://datatracker.ietf.org/doc/draft-litkowski-idr-rtc-interas/

• [presented at IDR in Toronto] - rewritten for peering-type pruning and NLRI type pruning. 
• Discussion: 
• Stephane: We request WG adoption: 
• John Scudder: As a WG member, we should adopt this point. 
• Tony P: Is similar to a previous draft? 

Flow Spec and Segment Routing  [30 minutes]
6) draft-litkowski-idr-flowspec-interfaceset [Stephane Litkowski] [5 minutes]
http://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/

• Discussion 
• Stephane: We request adoption requested on the list. 
• Acee Linden: Do offer any guidance for grouping the interfaces? 
• Stephane: We are grouping these flowspecification by interface type. 

7)draft-previdi-idr-bgpls-segment-routing-epe [Stefano Previdi] [10 minutes] 
http://datatracker.ietf.org/doc/draft-previdi-idr-bgpls-segment-routing-epe/

• Discussion
• Stefano: This is a post merge draft. 
• Uma Chunduri [Ericsson]: Clean up and consolidate the code points and move it to IANA section of the draft.
• Stefano: OK 
• 
  
•                                                              Same thing (consolidation and listing of all code points) applies to BGP-LSbase draft and 
• 
  
•                                                                theIANA link in the BGP-LS draft (version 10)  doesn’t work.
• 
  
• \

8) Advertising Per-node Admin Tags in BGP Link-State Advertisements [Pushpasis Sarkar] [10 minutes]  
http://datatracker.ietf.org/doc/draft-psarkar-idr-bgp-ls-node-admin-tag-extension/

• Discussion: 
• Pushpasis: Please note this draft was shownin previous IETFs. 
• Robin: Will this support inter-as TE? 
• Pushpasis: This will support inter-area TE.  I do not have examples of this in the draft.  
• Stephane: We may use the same allocation of the administrative tags across ASes.
• John: This is another WG adoption call. These WG may be rolling so that people can read drafts carefully. 

NextHop [10 minutes] 
====================
9) draft-decraene-idr-next-hop-capability-00 [10 minutes]
 http://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/

•  Bruno Decraene: This is a non-transitive BGP attribute. Capability is add/deleted with the next-hops.  Based on RFC6790 (Entropy label)
• Hannes: We have been discussing similar proposal for the IGPs.  It is only announced only if all your interfaces are supported. In IGP it is a node capabiity, and there is not eleciton odel. 
• Bruno: We can go in more detail with EGP and IGP.  
• David Lampster (jabber): Is this used on each route? How does this match with the other remote nexthop draft? 
• Bruno: It is used on each advertisement of route.  I do know the draft.    
• Robin: What is the step in the BGP nexthop? 
• Bruno: (missed)
• Robin: You must synchronize the entropy label and the nexthop.
• Bruno: Do you mean that you must synchronize for load balancing?  If so, it must be linked to route. 
• Robin: We proposed another draft with a list of next-hops. You can have many capabilities. 
• Keyur: Do you need a text on the route reflector to indicate if the route reflector is in the forwarding path? 
• Bruno: [discussion piece] 

 
Yang Section  [10 minutes] 
==========================
10) OpenConfig BGP Config Model Update  [Anees Shakih] [7 minutes] 
 http://datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/
 companion draft in rtrwg 
  http://datatracker.ietf.org/doc/draft-shaikh-rtgwg-policy-model/

• models: built out of the operators configuration model. 
• scope: configuration, multi-address families, operational state. 
• Format: uses new format for state. 
• Convergence: progression with   

 
11) Zhdankin BGP Config Model Update  [Keyur Patel] [3 minutes] 
http://datatracker.ietf.org/doc/draft-zhdankin-idr-bgp-cfg/

• discussion: 
• Keyur: We wish to have a design team and merge with the operators. 

BGP Controls [10 minutes]

12) Route Leak Detection [K. Sriram] [10 minutes] 
http://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigation-00   
[companion draft in grow
http://tools.ietf.org/html/draft-ietf-grow-route-leak-problem-definition-01 ]

Discussion: 

• Keyur: This is a good solution.  A provider receives a route from a customer, and then leaks it out. Does this help prevent part of the process. 
• Sriram: I need to examine this question, 
• Wes: Your taxonomy is really helpful. You use the word "intent", but you do not define it.  You use the words "up" or "lateral", but you do not define it.  It would be helpful. 
• Sriram: Is it on a customer link or provider link? 
• Wes: If you do not provide more detail on the solution.  We have community based filtering than NO_EXPORT community. Is it better than this? You have the RFC7454.  Please indicate if these will fix tis point. 
• Doug: There is a difference in prevention.  This is about detection and mitigation. 
• Wes: This is a good point.  This also brings up another point that we can infer routes the 
• Sriram: We request WG adoption.  
• John: Will you send a note to the WG chairs. 

New Concepts [30 minutes]
=========================
13) Draft Name: draft-li-spring-mpls-path-programming-01 [10 minutes] 
               draft-li-idr-mpls-path-programming-01
Speaker: Shunwan Zhuang
Duration: 10 minutes
Description: The BGP extensions has been enhanced for the MPP solutions. 
We would like to do the presentation to collect more comments.

• John: Unfortunately we do not have time for questions and comments.  Please send these to the list. 

14)  draft-fang-idr-bgplu-for-hsdn-00 [10]  [Luyuan Fang] 
BGP-LU for HSDN Label Distribution
http://datatracker.ietf.org/doc/draft-fang-idr-bgplu-for-hsdn/

This document describes the use of BGP Labeled Unicast (BGP-LU) with
   modified BGP Route Reflector (RR) operation for label distribution in
   the Hierarchical SDN (HSDN)control plane for the hyper-scale Data
   Center (DC) and cloud networks

• John: Unfortunately, we must have discussion on the list. 
• Sue: yakov picked up some of these concepts from a previously successful peer mechanism.   

15) Xiaohu Xu [10 minutes]
 https://tools.ietf.org/html/draft-xu-idr-bier-extensions-00 
 BIER: Bit Index Explicit Replication (BIER) is a new multicast forwarding
   architecture which doesn't require an explicit tree-building protocol
   and doesn't require intermediate routers to maintain any multicast
   state

• john: Please send discussions to the list.