IDR interim 6/29/2015
Time: 10:00 - 11:30am EDT

1. Agenda bashing 
1. draft-sriram-idr-route-leak-detection-mitigation-00 [10:00-10:15] 
Discussion: 

• 
  

2. Discussion of Route leaks [10:15 - 10:20] 
Discussion:

• Doug Montgomery: The draft is agnostic about how and where this is encoded. You could encoded this into the BGPSEC flows. You could also  encode this as a  new transitive attribute 
• Jeff: If you make this BGPSEC only, you will hinder deployment.
• If you make it a community, it will be stripped by some peoples community.
• Extended communities survive better. A new path attribute, is likely to survive.
• How quickly do want to see this adopted outside of BGPSEC?
• How does this integrate with people implementations? 
• People who support ROA implementations may not apply to this policy review of a route, but they will use it for detection.
• Doug: If we put it in BGPSEC, it could be under signed attributes. Or there is a  hybrid approach where you carryit under a signature, if not it is carried under a different form.
• Jeff: You'd like to see BGPSEC adopted. However, BGPSEC has a narrow deploy for the short term.  We do not intentionally secure BGP communities and BGP extended communities.
• If you want it in BGPSEC, you will need to change the BGPSEC. 
• If you make it a path attribute, it could be deployed immediately.
• Sriram: There are complementary techniques of prefix-filtering, and other techniques.  These can be a stop-gap prior to BGPSEC.  Will they adequately serve the purpose?  BGP router filter filters (prefix-filters) do not catch the all the routes.
• You suggesting it be as a BGP attributes.
• Jeff: There are providers that support ROA and strong IRR filtering and this device. What would be the best way to get this done for these operators that care.  
• Sriram:
• Short of the BGPSEC, you will need a different mechanism.
• (BGP communities, BGP attributes)
• It will fix accidental route leaks, but not malicious route leaks.
• Do we need a signature?  Is this helpful outside of preventing accidental leaks? 
• Jeff: This is the issue I mentioned?
• Sriram: Any other questions or comments? 
• Sue: I will post a summary of this to the mail list and ask people to comment. 

2. draft-jdurand-auto-bfd.txt  [10:20 - 10:30] [Jerome Durand]
Discussion: 

•  Acee:  For IP FRR, this is a useful solution. It is important to document the solution. Is this standard track solution or information?
• Jeff: Some of the interesting.  This solution covers that the other draft (draft-ietf-rs-bfd) covers. 
• We are protecting the next-hops rather than the BGP session [? Jeff please confirm this comment. 
• This analogous to your FRR, we are protecting  the connection. where  If you are using an LDP tunnel, you are protecting the tunnel. 
• What happens if this overlaps the session protection with the next-hop protection? What is the conflict of  the protection.  For the FRR case, we will need more discussion. 
• For BGP, this is  is a useful addition. 
• Acee: I went to this solution, because it is my interest.
• Jeff: All BFD sessions go to protect the session. It makes the protection of connections problematic. 
• Acee: Ok. You think this is standards track because this impacts the BFD normal operation. 
• JEff: BFD is there to protect the session.  
• for the FRR case, you protect the connection.
• For the BGP router server, you are interested to protect the informatino flow (?) 
• Jerome: It can be a set of policy with route-map, BFD route state, and prefixes.
• Jeff: I agree. The case that  makes the most sense is the route ineligiblity. 
• You could treat an unresolvable BFD a high metric. 
• You can allow it to be considered as a last resort. 
• 
  

3. draft-rosen-idr-tunnel-encaps-00  [10:30 - 10:45] [Keyur Patel]
Discussion: 

• Jeff: I raised objections.  This draft covers those objections. 

4. ietf-idr-bgp-nh-cost-02 [10:45-11:00] [IIlya Varlashkin]
Discussion: 

• John: Is there some distinguished unreachable or infinity that you can advertise for this cost?
• Ilya: If you are sending this information via BGP-LS, you can send a reachable or 
• unreachable. 
• Robert: We had a marker that was a high cost. 
• John: Let me think about this, and send a note. 
• Sue: I thought this was to remove the route oscillation for no-announcement to announcement. 
• John: The RR gives the universe of Next-hops, and the client says I can get NH hoip.
• Ilya: In -00 draft, we used max-ed out cost for the requests.
• In the original draft, the original RR would send out the reachability 
• We thought this feature was not necessary.
• No information is received regarding the client on NH, then RR uses IGP 
• If the route receives, 
• JohN: This is one viable answer. 

5. Record Next-Hop features [Sue Hares] [11:00-11:10] 
 
Discussion: 

•     David Freeman - what do you use for a nexthop?  What is it from your perspective?
• Sue: The NH or implied NH in the protocol.
• DF: If I do NH on one segment as myself, but a different on a different semgnet, you use that interface's NH?
• SH: If you have 2 BGP speakers you're talking to; if you send it to one and do next-hop-self, you will record that NHS.  If on the other and you don't have NHS, it won't add this particular attribute.  It is the combo of recording it plus the action that causes the NH to change.  It's a case of recording changes.  You may lose history if the node doesn't support this feature.
• Ilya: Do you propose any form of standardizing this for external peers - information leaking/privacy considerations?
• SH: You're permitted to sanitize, per draft; need some feedback here.  
• JH: Consider non-transitive like AIGP.
• SH: There may be clouds of ebgp within the same domain.  May want the ebgp to be permeable.  Left it as a knob.  Reasonable?
• SH: Can consider capability.
• Keyur Patel: The problem with non-transitive aspect is router in the middle, it'll drop it.  Also route-reflectors.
• JH: At what point do we merge with the similar drafts such as path-record and bgp-timestamp?
• SH: Agreed, we should talk about it.

6. Discussion of Next-Hop technology [11:10-11:30] 

• Sue: We will need a consistent set of drafts regarding next-hop.  I will raise questions on the list, and encourage an authors session at IETF 93. 

Action items: 
    1) Sue Hares will post a set of questions on route-leaks
    2) Sue Hares will post a set of questinos on draft-jdurand-auto-bfd and draft-ietf-idr-rs-bfd. 
       (Hopefully Jeff will help with the discussion)
    3) Keyur Patel will post questions on draft-rosen-idr-tunnel-encaps-00, and Sue will start WG adoption call on 7/3/2015. 
    4) Sue Hares will organize a "record" and instrument discussion with co-authors before IETF.
    5) Sue Hares will organize a cohesive "next-hop" session at IETF for next-hop related authors.  

IDR interim 6/29/2015 
Monday, June 29, 2015 
10:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1.5 hrs 


Join WebEx meeting 
https://ietf.webex.com/ietf/j.php?MTID=m2151dbd171e8db03550073dd511ba2b2

Meeting number:         644 932 691 
Meeting password:        bgp.and.john

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: 644 932 691

Blue sheets: 
http://etherpad.tools.ietf.org:9000/p/idr-interim-june-29-2015-vBluesheets

Minutes
http://etherpad.tools.ietf.org:9000/p/idr-interim-June-29-2015-minutes