IETF
pim
pim@jabber.ietf.org
Tuesday, 15 November 2011< ^ >
Room Configuration

GMT+0
[00:57:09] Daniel King joins the room
[01:01:10] revathi joins the room
[01:04:25] jwatwood joins the room
[01:06:03] Bill joins the room
[01:08:05] marshall joins the room
[01:08:12] <marshall> Hello.
[01:08:17] <Daniel King> o/
[01:08:18] <marshall> I will be your jabber scribe today
[01:08:30] <marshall> Agenda bashing
[01:08:38] <marshall> NOTE WELL
[01:08:50] <marshall> status
[01:08:57] <marshall> A good year for RFCs
[01:09:03] <marshall> new work items
[01:09:16] <marshall> some drafts to discuss
[01:09:28] <marshall> Stig : ietf-pim-port is done
[01:09:55] <marshall> Mike : Pop count has gone through WGLC without much response
[01:10:06] <marshall> 3 support the draft
[01:10:48] <marshall> Lenny opposed : saying PIM shouldn't carry topolgoy info
[01:11:20] <marshall> Greg S : I think he misunderstood the intention behind pop-=count
[01:11:46] <marshall> Mike : I hesitate to carry on with such weak respone
[01:11:58] <marshall> Stig : Check the room
[01:12:31] <marshall> Mike : OK : If PIM pop count should proceed (as experimental)
[01:12:41] <marshall> raise of hands : 7 in favor 0 opposed
[01:13:08] <marshall> Mike : We'll take it to the list
[01:13:19] <marshall> I think there is consensus here
[01:14:28] <marshall> Vero Zheng : 4601 revision
[01:14:39] <marshall> advance PIM from PS to DS
[01:14:58] <marshall> implementation and deployment report requested by IESG
[01:15:19] <marshall> Stig : I don't think it should be that hard to reach internet standard
[01:15:47] <marshall> the big concern is with down refs
[01:16:01] <marshall> Vero : This work is supporting work
[01:16:15] <marshall> 4601bis - draft adopted by WG in October
[01:16:39] <marshall> addressed errata, optional features, and revved to 01 version
[01:16:57] <marshall> we are preparing a survey with questions about operational experience
[01:17:26] <marshall> less than 10 questions - very straightforward
[01:17:47] <marshall> have you deployed
[01:17:50] <marshall> which version
[01:17:55] <marshall> interop issues
[01:18:23] <marshall> do you deploy SM and DM and route between them ?
[01:18:45] <marshall> also SSM BSR etc
[01:19:12] <marshall> then there are questions for implementers
[01:19:27] <marshall> (*,*,RP) implemented ?
[01:20:32] <marshall> simple and straightforward questions
[01:21:37] <marshall> Li (Cisco) : 4601 vs 2362 - this is not a yes or no question
[01:21:37] <marshall> also
[01:22:25] <marshall> fdfd
[01:22:44] Nathaniel Borenstein joins the room
[01:23:10] Nathaniel Borenstein leaves the room
[01:24:33] <marshall> test
[01:25:22] <Bill> test ack
[01:26:09] <marshall> this was dead for a while
[01:26:12] <marshall> sorry
[01:26:37] <marshall> I suggested that the PIM survey ask about IPV6 vs v4 experience
[01:27:03] <marshall> Thomas : You should make sure it is confidential ?
[01:27:52] <marshall> Jeffery : to recap : Specific feature sets
[01:28:04] <marshall> for operators, which are you using
[01:28:09] <marshall> v4 vs v6
[01:28:16] cmorgan joins the room
[01:28:23] <marshall> survey should be confidential and sent to a 3rd party
[01:28:28] cmorgan leaves the room
[01:28:36] <marshall> Marshall Eubanks volunteered to be the neutral party
[01:30:23] stevey joins the room
[01:30:37] stevey leaves the room
[01:30:50] <marshall> Toerless : This should be in two steps - what is deployed should be public, the operators should be more private and confidential
[01:30:55] stevey joins the room
[01:31:02] <marshall> Marshall : Ask about Bidir ?
[01:31:09] <marshall> [not in this draft]
Room Configuration
[01:31:29] Chatroom configuration modified
[01:31:33] stevey leaves the room
[01:32:11] <jwatwood> You better!!!
[01:32:47] <marshall> NEXT
[01:32:52] <jwatwood> I will look at what is in the draft and comment to the list.
[01:32:59] <marshall> PIM ECMP
[01:33:12] <marshall> first presented at ietf 80
[01:33:18] <marshall> accepted after ietf 81
[01:33:29] <marshall> changed name to ECMP redirect
[01:33:39] <marshall> that's the changes
[01:33:51] <marshall> Let's go through the feature quickly
[01:34:24] <marshall> current PIM ECMP RPE selection is downstream and uses address caching and cannot consider load
[01:34:39] <marshall> and cannot handle sticky PPF decisions
[01:34:53] <marshall> no mechanism to "assert" between different paths
[01:35:28] <marshall> we designed ECMP redirect message to allow upstream routers to recommend a different path.
[01:35:45] <marshall> also, allows downstream routers to consider bandwidth
[01:35:51] <marshall> key features
[01:35:59] <marshall> this is triggered by PIM joins
[01:36:08] <marshall> sent in a different subnet
[01:36:11] <marshall> use
[01:36:18] <marshall> "non-routing" metrics
[01:36:33] <marshall> IANA NUMBERS have been requested
[01:36:40] <marshall> not granted yet of course
[01:37:30] <marshall> Only HELLO messages can be easily assigned
[01:37:37] <marshall> other messages require an RFC
[01:37:45] <marshall> authors want WGLC
[01:38:32] <marshall> Stig : We only have 5 types, so we need to be a bit careful
[01:38:51] <marshall> I would be less concerned for join attributes
[01:39:12] <marshall> Dino : My suggestion would be to add an extension type
[01:39:50] <marshall> Stig : We may need to think about extending the types
[01:40:43] <marshall> We haven't gotten any change requests for 8 months or so
[01:40:50] <marshall> for PS
[01:42:32] <marshall> Results of hand raise : 4 in favor of wglc no opposed
[01:42:42] <marshall> Dino : Any implementations
[01:42:44] <marshall> One
[01:43:27] <marshall> NEXT
[01:43:30] <marshall> Hitoshi
[01:43:47] <marshall> IGMP explicit membership tracking function
[01:43:55] <marshall> 4 objectives
[01:44:04] <marshall> per host acconting
[01:44:24] <marshall> reducing number of query messages
[01:46:53] <marshall> [sorry - interrupt]
[01:47:25] <marshall> Shortening leave latencies
[01:48:29] <marshall> test
[01:50:17] <marshall> test
[01:50:41] <marshall> did anyone else notice that this jabber was down ?
[01:51:06] <jwatwood> I have seen two "test" messges.
[01:51:17] <marshall> Toerless : You are not supposed to be changing IGMP behavior
[01:51:24] <marshall> when for the test messages ?
[01:51:36] <marshall> quite recently, or strung out "
[01:51:37] <marshall> ?
[01:51:55] <jwatwood> 8:48 and 8:50 in Montreal; 9:48 in Taipei
[01:52:29] <marshall> Toerless : It is important to send conventional messages for those that don't support this
[01:52:42] <marshall> the one thing that isn't mentioned is snooping ?
[01:52:54] <marshall> How do I know if devices are snooping
[01:53:44] <marshall> @jwatwood@jabber.org - IF This happens again, I will send a "please RSVP" message - ping me back when you see it
[01:54:02] <jwatwood> ack
[01:54:21] <marshall> Toerless : No one has shown proof that reduicng messages is a requrement
[01:54:37] <marshall> Hitoshi : on wireless networks this is important
[01:54:53] <marshall> Toerless : then we need to look at what are the goals we are trying to acheive
[01:56:22] <marshall> Toerless : if this is important, we should look at in depth and find a solution that would work for everyone
[01:57:06] <marshall> Toerless : There is text in the document, but I don't think it's the right text
[01:57:25] Daniel King leaves the room
[01:57:28] <marshall> Toerless : We would not need this optimization for the primary use case
[01:57:33] Nathaniel Borenstein joins the room
[01:57:41] Nathaniel Borenstein leaves the room
[01:59:54] <marshall> Stig : This document is informational
[02:00:12] <marshall> so as long as it is informational, it is ok to discuss different tradeoffs, etc.
[02:02:54] <marshall> Hitoshi : Next steps ?
[02:03:01] <marshall> This is informational
[02:03:07] <marshall> I would prefer BCP
[02:03:22] <marshall> We need some use cases
[02:03:53] <marshall> next
[02:04:02] <marshall> PIM DR Load balancing
[02:04:22] <marshall> Sri from Cisco
[02:04:25] <marshall> new draft
[02:05:01] <marshall> today, DR election is given by DR priority or IP address
[02:05:15] <marshall> failover can take a long time as state is rebuilt
[02:05:22] <marshall> plus, one router does all the work
[02:05:52] <marshall> proposal : use hash function to determine which R becomes the GDR
[02:06:13] <marshall> only applicable for the last hop router
[02:06:28] <marshall> Limiting it to SM/SSM/DM only
[02:06:46] <marshall> new capability : router announces hash masks
[02:07:37] <marshall> how do we create the forwarding state?
[02:08:25] <marshall> a candidate runs the hash algorithm to determine if it is the new GDR
[02:08:59] <marshall> a GDR becoming a non-GDR MAY chose not remove the state, leading to an assert
[02:17:20] <marshall> discussion at the mike [including me] - if a router goes up or down, only flows going through that router should have to change
[02:19:44] <marshall> question of intended status : experimental or PS ?
[02:20:08] <marshall> Mike McBride : Who would support ?
[02:20:12] <marshall> 12 pro
[02:20:16] <marshall> none opposed
[02:20:40] <marshall> Thomas : The draft is suggesting at GDR is used as a tie breaker
[02:21:09] <marshall> I suggest that the answer to the 3rd question should be yes
[02:21:52] adrianfarrel joins the room
[02:22:01] <marshall> Next :
[02:22:03] <marshall> Jeffery
[02:22:17] <marshall> Unnecessary upstream traffic
[02:22:36] <marshall> scenario # 1 - no receivers
[02:22:47] <marshall> dropped at RP
[02:23:05] <marshall> should be dropped earlier
[02:23:06] <marshall> scenario # 2
[02:24:07] <marshall> this is hard to describe in words but I think it is bascally RP on a stick
[02:24:17] <marshall> fix for scenario 1
[02:25:02] <marshall> RP HAS (*,G-PREFIX) notification route
[02:28:16] <marshall> scenario 2 : RP sens periodic neighbor-speciic
[02:29:05] <marshall> this propagates until it gets to a router with more than 2 downstreams
[02:30:32] <marshall> Dino : Is there additional receiver state ?
[02:30:42] <marshall> Marshall Does the RP keep state
[02:31:47] <marshall> a timer to stop things if the downstream stops refreshing
[02:31:54] <marshall> the state
[02:32:18] <marshall> RSVP : dead at 10:32:04 Tiawan time
[02:32:53] <jwatwood> I see your RSVP
[02:34:59] <marshall> RSVP : Appears dead at 10:33:00 Taiwan time
[02:34:59] <marshall> RSVP : Appears dead at 10:34:00 Taiwan time
[02:35:00] <marshall> RSVP : Appears dead at 10:35:00 Taiwan time
[02:35:50] <marshall> Just got all my RSVPs at ~ 10:35:30 TT
[02:38:52] <marshall> Bill, are you here or remote ?
[02:38:56] <Bill> I am upstairs
[02:39:17] <Bill> I don't know whether 2 floors away counts as "here" or not :-)
[02:40:30] <marshall> sounds like here to me :)
[02:42:33] <marshall> Toerless : This can probaby all be made to work.. It makes a previously simple protocol, BiDir PIM. and really complexifies it.
[02:42:39] <marshall> is there a use case ?
[02:42:56] <marshall> We don't want to have data triggered events in BiDir PIM
[02:43:10] <marshall> So, I have a motivational issue
[02:43:40] <marshall> When you have the use case, why not use PIM SM with spt threshold infinity
[02:43:48] <marshall> PIM has been stable for 10 years
[02:44:03] <marshall> I need a lot more motivation
[02:44:53] <marshall> Jeffery : So far,BiDir pim has only been used in scenarios with receivers everywhere
[02:45:50] <marshall> Ice : BiDir only tends to be used with lots of senders, so this won't get used. It seems like we are adding PIM DM into BiDir
[02:46:24] <marshall> Greg Shepherd : How would this enable more utilization for BDP?
[02:46:58] <marshall> Why would operators care ?
[02:47:08] <marshall> BiDir PIM has a specific niche
[02:49:06] <marshall> Dino : This is a state bandwidth tradeoff and I think these guys are saying, don't do it.
[02:49:24] <marshall> this does feel like dense mode.
[02:51:01] <marshall> Greg S : If you can better describe the use case it would help me.
[02:54:24] <jwatwood> No.
[02:54:54] <marshall> Dino : You are telling him,, don't use BiDir PIM, but he may feel that there is a need for BiDir PIm and thus this as an optimization
[02:55:12] <marshall> No one supported taking on the draft.
[02:55:19] <marshall> NEXT
[02:55:20] <marshall> Ice
[02:55:28] <marshall> PIM source discovery
[02:55:52] <marshall> problem highly redundant mcast network with no single point of failure
[02:56:04] <marshall> supproting source discover
[02:56:05] <marshall> y
[02:56:14] <marshall> this sounds like PIM SSM
[02:56:25] <marshall> but source discovery remains an issue
[02:56:42] <marshall> if sources are known, SSM mapping is used
[02:57:14] <marshall> this focus on a specific situation
[02:57:26] <marshall> there is no rp
[02:57:39] <marshall> FHR detects a new active source
[02:57:51] <marshall> S,G mapping is send using RPF flooding
[02:58:11] <marshall> BSR and Auto-RP do this now
[02:58:28] <marshall> BSR seems like a logical choice
[03:00:17] <marshall> Each FHR connected to a source becomes a BSR router
[03:00:30] <marshall> the first packet is NOT delivered
[03:00:47] <marshall> SDR depends on it
[03:01:28] <marshall> MANY applications do not depend on first packet
[03:01:50] <marshall> applications that are could use PIM BiDir
[03:02:24] <marshall> Want feedback
[03:02:36] adrianfarrel leaves the room
[03:02:51] <marshall> Thomas : The problem statement is good
[03:03:03] <marshall> the tradeoff of not delivering first packet is reasonable
[03:03:42] <marshall> BUT, you are triggering control plane events based on data plane events
[03:03:58] <marshall> ICE : But the new packets already create new states
[03:04:40] <marshall> Thomas : agreed - but you have to damp the behavior
[03:04:49] <marshall> also, I don't think that BSR is the solution
[03:06:22] <marshall> Toerless : I am motived to see a solution - something like situation awareness in the military, where you don't want RPs
[03:06:52] <marshall> BSR is a RPF flooding mechanism
[03:07:36] <marshall> Ice : I don't think that we should overload the IGP mechanism
[03:08:12] <marshall> Toerless : this is not a multucast specific problem
[03:08:43] hoyaj@jabber.org joins the room
[03:09:15] <marshall> this is somewhat backwards facing
[03:10:23] <marshall> Dino : I think it is good to do this at a network layer. I have a database - the LISP database, which need not be data event driven
[03:10:36] hoyaj@jabber.org leaves the room
[03:10:46] <marshall> you could inject (S,G) joins and we could make it scale quite well
[03:11:12] <marshall> also, you may want to reach AMT receivers not on the multicast network
[03:12:00] <marshall> Thomas : Source discovery is done in MSDP and L3VPNs, where it is done with BGP
[03:12:26] <marshall> Dino : This would inject data driven events into BGP, and that cannot be good
[03:12:54] <marshall> We need to get away from data driven events
[03:13:07] <marshall> Stig : Msnip
[03:14:00] <marshall> Thomas : BGP would give you congestion control and authentication
[03:14:31] <marshall> Siri : WOuldn't this make BSR very chatty in the network ?
[03:15:02] <marshall> Dino : If it is trigger based it will be chatty and if it isn't there will be join latency problems
[03:16:20] <marshall> Mike : Who wants to take this draft, which uses BSR
[03:16:46] <marshall> Dino : Do intermediate routers have to store state ?
[03:16:50] <marshall> Ice : no
[03:17:10] Yuri Nawata joins the room
[03:17:18] Yuri Nawata leaves the room
[03:18:13] <marshall> Greg Shepherd : Knowing the scars from certain choices, I am concerned about moving this forward without clear instructions on how it is to be used
[03:18:26] Bill leaves the room: Computer went to sleep
[03:18:27] <marshall> Thomas : The problem statement looks decent
[03:18:45] <marshall> we could separate the problem statement and the solution
[03:19:45] <marshall> no consensus was called
[03:19:51] <marshall> this will be taken to the list
[03:19:54] <marshall> NEXT
[03:20:06] <marshall> Dino : Mulicast only fast reroute
[03:20:29] <marshall> idea is to swtich tree branches is < 50 msec
[03:20:58] <marshall> solution is to use preinstalled branches - no changes to PIM
[03:21:16] <marshall> on;y changes required at the edge
[03:28:00] Bill joins the room
[03:28:14] arifumi joins the room
[03:28:23] arifumi leaves the room
[03:34:59] <jwatwood> Thanks, marshall
[03:36:55] Bill leaves the room
[03:38:12] glen joins the room
[03:38:39] jwatwood leaves the room
[03:39:24] glen leaves the room
[03:49:19] stevey joins the room
[03:49:24] stevey leaves the room
[03:50:57] revathi leaves the room
[03:56:18] marshall leaves the room
[04:39:14] marshall joins the room
[04:41:14] marshall leaves the room
[04:51:32] adrianfarrel joins the room
[05:05:07] adrianfarrel leaves the room
[05:09:35] adrianfarrel joins the room
[05:54:05] adrianfarrel leaves the room
[19:45:59] leebingice joins the room
[19:46:58] <leebingice> hi
[23:04:53] leebingice leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!