IETF
idr
idr@jabber.ietf.org
Friday, November 8, 2013< ^ >
Room Configuration
Room Occupants

GMT+0
[15:21:36] Pratima Kini joins the room
[15:27:52] Pratima Kini leaves the room
[16:28:36] Shane Amante joins the room
[16:28:39] Shane Amante leaves the room
[16:28:49] shane joins the room
[16:35:07] Pratima Kini joins the room
[17:02:11] <shane> Hi, I'll be Jabber scribe for the IDR @ IETF-88 WG meeting. Please direct questions to me and I'll relay them to the mic.
[17:03:43] Jeffrey Haas joins the room
[17:03:46] <shane> JohnS has asked me to be minute-taker during Jeff Haas' talks, so I might be slow/non-responsive during that time
[17:03:50] <shane> Meeting starting
[17:03:54] <shane> Note Well
[17:04:10] Wes George joins the room
[17:04:58] <shane> Document Status
[17:05:22] <shane> John to send to list ASAP, b/c of broken laptop during the week :(
[17:05:37] <shane> Agenda
[17:05:53] <shane> Change to agenda: Keyur is moved to top of agenda, other than that … no changes
[17:06:19] <shane> Keyur: BGP vector routing
[17:06:55] <shane> Motivation
[17:07:38] <shane> need scalable control plane solution to route traffic thru ordered set of nodes
[17:07:57] <shane> BGP Vector Routing
[17:08:17] <shane> - create arbitrary svc topologies and facilitate svc chaining
[17:08:32] <shane> - new BGP attribute: Vector Node attr.
[17:09:14] <shane> next slide: BGP Vector Routing (cont'd)
[17:09:31] <shane> - attr. can be applied to any BGP AFI
[17:10:03] <shane> - creation of BGP Vector Node attr. is outside scope of doc.
[17:10:13] <shane> next slide: BGP Venctor Node Attr. TLV's
[17:10:27] <shane> - Type 1 & 2 TLV's
[17:11:31] <shane> next slide: BGP Vector Node Attr. Rules
[17:11:45] <shane> - 4 rules defined to process BGP Vector Node Attr.
[17:12:42] <shane> next slide: BGP Vector Node Attr. Rules (cont'd)
[17:12:57] <shane> Questions?
[17:13:16] <shane> Lucy Yong: Is Vector Node Attr. new attribute?
[17:13:17] <shane> A: Yes
[17:13:46] <shane> Lucy: If this is applied to VPN AFI, then how does it correlate to RT filterings?
[17:14:11] <shane> A: Routes in VPN willbe tagged with own RT's
[17:14:41] <shane> Robert: It works in context of the VPN, but doesn't override what the VPN RT filtering does
[17:15:21] <shane> Lucy: could use destination routing or could use vector routing for fwd'ing
[17:16:05] <shane> Lucy: Could have route thru svc chain and not thru destination routing fwd'ing table by VPN
[17:16:13] <shane> SteveP @ Google
[17:16:35] <shane> Xiohu: Any node in vector route, BGP router or non-BGP speaking router?
[17:16:37] <shane> A: Either
[17:17:18] <shane> Xiahu: How can router fwd packet further when recv'ing BGP vector route?
[17:17:28] <shane> Xiahu: How can you get next-hop from BGP?
[17:17:40] <shane> Keyur: The transit router needs to support BGP
[17:17:53] <shane> Keyur: Does not have any impact on fwd'ing
[17:18:25] <shane> Xiaohu: Need list of nodes in BGP vector node, otherwise routers will not know how to fwd packets
[17:18:34] <shane> Keyur: What about static routes?
[17:18:48] <shane> Lucy: Need some local cfg
[17:19:09] <shane> Robert: No static configuration needed. Transit nodes need to speak BGP
[17:19:51] <shane> JohnS: Re: WG adoption? Don't know if SFC BoF will get chartered, but seemed strong support to do so. If that group gets chartered, they'll work on svc chaining architecture.
[17:20:13] <shane> Robert: if we remove service chaining and only talk about TE, then would we adopt this as WG doc
[17:20:19] <shane> JohnS: Probably yes
[17:21:00] <shane> JohnS: Svc chianing is kind of a misnomer and it's better described as a svc graph, but current draft talks about svc chaining. So, need to put in context of SFC architecture.
[17:21:19] <shane> Keyur: We could build graphs off paths
[17:21:27] <shane> in future rev. of draft
[17:22:32] <shane> Rudiger Volk: Nervous is to see Security Considerations that say "no new problems", but with a new proposal that affects steering of traffic
[17:23:00] <shane> Keyur: We have made sure that this works with security mechanisms that a provider implements.
[17:23:36] <shane> Rudiger: if attr. are passed Inter-Domain, I find it hard to believe that w/out mechanisms to secure integrity of data passed around, then I wouldn't trust that data.
[17:23:49] <shane> JohnS: Would agree. Need to beef up Sec. Considerations in present draft.
[17:24:17] <shane> RobertR: Need to document that more, but we do check if NH's are inserted by nodes in the AS.
[17:24:34] <shane> JohnS: Need to translate comments into the draft
[17:24:45] <shane> RobertR: Draft says Inter-Domain is out-of-scope.
[17:25:01] <shane> RobertR: All protocol ext. will happen in respective WG's
[17:25:19] <shane> JohnS: Saying Inter-Domain is out-of-scope means we can ignore it.
[17:25:50] <shane> JohnS: Yes, work on a routing protocol ext. will happen in respective WG, but doesn't mean we can ignore outcome of arch. defined by SFC
[17:26:20] <shane> JohnS: if you have a strong proposal for TE, then great.
[17:26:48] <shane> JohnS: not saying we can't work on this in the WG, certainly can discuss it more on the list, etc.  Just want to make sure we follow an order or operations.
[17:27:10] <shane> RR: What would make you comfortable that this is TE only and could get adopted now?
[17:27:28] <shane> JS: Would turn that around to WG to see if there's interest in the WG?
[17:27:49] <shane> JH @ Ericcson - any comment on NH reachability?  Do all NH's need to be reachable or jsut first one?
[17:28:06] <shane> RR: checking for reachability on NH's in IGP and final one. If we need more, then let's talk about it.
[17:28:27] <shane> KP: May need text in draft to talk about long-length vector route
[17:29:06] <shane> LY: TE might be interesting for better traffic direction, but need to think about loops
[17:29:40] <shane> RR: Not really loops … b/c list of NH's is non-repetitive. If you want to go thru same node twice, then operator would encode diff. IP address for same node.
[17:30:28] <shane> Eric Rosen: In SFC BoF, could create svc chain based on DPI … kind of struggling to see how this mechanism could be used in the context of DPI
[17:31:37] <shane> RR: If I want to classify, I can use Flow-Spec
[17:31:47] <shane> ER: Instead of using DPI, use Flow-Spec?
[17:31:59] <shane> RR: Yes. How we build paths it out-of-scope of how we encode it in BGP
[17:32:16] <shane> KP: Does not dictate that chain is followed hop-by-hop
[17:32:48] <shane> ER: What happens if a mid-point wants to re-classify it, then how is that handled?
[17:33:03] <shane> RR: ???
[17:33:15] <shane> Tom Morin: ??
[17:33:22] <shane> LY: How do you plan to handle TTL?
[17:33:42] <shane> KP: We don't, because it's a control plane solution
[17:33:53] <shane> LY: How do you expect fwd'ing plane to handle TTL
[17:34:17] <shane> KP: Loop cannot be created, b/c it's an ordered list
[17:34:42] <shane> JS: Just told Eric that you can divert away from one svc chain onto another, then this could be an issue
[17:34:48] <shane> KP: THat's just a policy
[17:35:08] <shane> JS: In curernt protocol, we could create a fwd'ing loop, but TTL would still apply
[17:35:15] <shane> JS: Questions to WG
[17:35:30] <shane> JS: Authors have said there's a SFC use case and TE use case
[17:35:42] <shane> JS: How many people have read the draft?  A: Quite a lot.
[17:36:07] <shane> JS: Should WG work on TE use case in the draft?
[17:36:23] <shane> Robin @ Huawei: The TE use case has come up several times in the past.
[17:36:36] <shane> JS: Valid point, not the first time that TE has come up.
[17:37:14] <shane> JS: How many people think this is ready for adoption in context of TE?  A: Small # of hands?
[17:37:24] <shane> JS: How many think use cases need more work?  Large # of hands
[17:37:35] <shane> JS: How many think adoption for SFC use case?  A: No hands
[17:37:50] <shane> JS: Sense of room is please continue to work on use-cases.
[17:38:06] <shane> JS: Thx for productive conversation.
[17:38:20] <shane> LY/JS: throw IDR in draft name to make it easier to find
[17:38:24] <shane> Next presenter: Eric Rosen
[17:38:38] <shane> AIGP Last Call Issues
[17:40:11] <shane> No objects raised to "meat" of draft, but to error-handling, leakake protection at admin boundaries and stuff that might effect other people/domains
[17:40:16] <shane> Next Slide: AIGP
[17:41:22] <shane> - AIGP is non-transitive attr. so must be discarded when not recognized
[17:42:00] <shane> Next Slide: Error Handling for Malformed AIGP attribute
[17:42:10] <shane> - Not clearly specified in draft
[17:42:17] <Jeffrey Haas> Is there anyone in channel not also in the room?  If so, Shane might be able to slow down his scribing to only backup minutes.
[17:42:50] <shane> good point Jeff :)  Speak up soon. :)
[17:43:37] <shane> Next slide: Can the Non-Transivity Break?
[17:45:37] Kazuya Okada joins the room
[17:45:49] Kazuya Okada leaves the room
[17:46:19] <shane> Next slide: TLV Encoding Issues
[17:50:17] <shane> JS: Question on multiple TLV with same code point. Have you thought about reverse processing order and made sure it's OK?
[17:50:57] <shane> BD (Orange): Diff. than what happens in draft-error-handling
[17:51:30] <Pratima Kini> I have a comment/question on the AIGP draft
The draft needs to define the behavior when the AIGP value has reached the maximum.
[17:51:50] <shane> Pratima: want me to ask that at the mic?
[17:51:54] <Pratima Kini> yes please
[17:51:57] <shane> OK
[17:52:48] slm joins the room
[17:53:05] <shane> Pratima: ER said it wasn't one of the LC issues
[17:53:44] <shane> JS: I think it would be appropriate to say something about that in the draft, even if it didn't come up in LC.  Likely going to see the issue during IESG or IETF LC.
[17:54:12] <shane> SB: What is best for the protocol? To fix it or not fix it?
[17:54:19] <shane> ER: The question is it is broken?
[17:54:43] <shane> Rob Shakir: those are 2 diff. questions - will it break is the real question
[17:55:18] Sriganesh Kini joins the room
[17:55:35] <shane> ER: concerned if this is an actual problem or not. This has been deployed for a # of years, so reluctant to make potentially unnecessary changes.
[17:56:56] <Pratima Kini> So the metric should not wrap around. Is that what is said
[17:57:03] <Jeffrey Haas> correct
[17:57:06] <Pratima Kini> thanks
[17:57:28] <shane> Next slide: Disabled by Default
[17:58:23] Sriganesh Kini leaves the room
[17:58:40] <Jeffrey Haas> http://tools.ietf.org/wg/idr/minutes - fyi.  
[18:00:56] <shane> OK, I'm switching over to minute taker.  
[18:01:02] <shane> backup minute taker
[18:01:34] Pratima Kini leaves the room
[18:13:34] slm leaves the room
[18:15:37] rjs joins the room
[18:26:33] <shane> just fyi for those who entered the room
[18:26:49] <shane> i'm taking minutes, please follow etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-88-idr?useMonospaceFont=true
[18:31:38] Lou joins the room
[18:33:24] <Jeffrey Haas> Etherpad is locking up on me.
[18:35:46] slm joins the room
[18:38:45] <shane> jeff: etherpad is working OK for me, so I'll keep doing minutes
[18:53:25] Lou leaves the room
[18:56:02] Pratima Kini joins the room
[19:01:31] Jeffrey Haas leaves the room
[19:03:09] slm leaves the room
[19:03:24] shane leaves the room
[19:03:30] Pratima Kini leaves the room
[19:04:12] rjs leaves the room
[19:13:23] slm joins the room
[19:18:38] Wes George leaves the room
[19:20:50] slm leaves the room
[19:24:13] Wes George joins the room
[19:36:38] Wes George leaves the room
[20:32:01] Jeffrey Haas joins the room
[20:36:48] slm joins the room
[21:10:30] Jeffrey Haas leaves the room
[21:46:32] slm leaves the room
[23:31:26] Pratima Kini joins the room
[23:31:29] Pratima Kini leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!