[17:33:31] fenghongyan2009 joins the room [17:34:11] fenghongyan2009 leaves the room [18:07:45] nordmark joins the room [18:20:59] alst joins the room [18:21:36] alst leaves the room [18:24:59] alst joins the room [18:25:06] alst leaves the room [18:40:24] nordmark leaves the room [18:40:33] nordmark joins the room [19:56:53] Robert Raszuk joins the room [20:08:02] Bill joins the room [20:08:28] I'm the jabber scribe. [20:08:50] We're going over the agenda now. [20:09:54] Agenda and status: http://www3.ietf.org/proceedings/09mar/slides/trill-0.ppt [20:11:23] draft-ietf-trill-prob-06 is intended to resolve AD DISCUSS comments [20:11:43] draft-ietf-trill-rbridge-arch-05 has timed out, and the chairs think it should be dropped [20:12:53] draft-ietf-trill-rbridge-protocol-12: WG Last Call comments substantially resolved, for review by IEEE 802.1 and IETF experts Bernard Aboba and Dan Romascanu [20:13:28] draft-trill-rbridge-vlan-mapping-00: Ready for WG Last Call? [20:14:19] Polling the room: how many people have read it? About 5. [20:16:30] A handful of people have volunteered to read vlan-mapping so that the wg definitely gets feedback for WG Last Call [20:17:25] Will do a 3-week WG Last Call, expect reviews from at least the people who volunteered, others should feel free to review too [20:18:33] Wes Beebee joins the room [20:18:41] Protocol document was liaised to IEEE 802.1 and their response is available [20:19:42] 3 relevant non-TRILL WG drafts: draft-ietf-isis-layer2, draft-eastlake-trill-rbridge-options, draft-eastlake-trill-rbridge-notes [20:20:06] Wes Beebee leaves the room [20:22:02] Two kinds of Hello: http://www3.ietf.org/proceedings/09mar/slides/trill-4.ppt [20:23:40] Little Hellos to ensure that you hear each other (Protective) and Big Hellos (Adjacency) [20:27:33] Q: Why do you need the big one? [20:27:58] A: There's data in there that we took out of the little one; also the MTU validation [20:28:45] Q: Just say never send payloads greater than 1500 bytes [20:29:41] A: What value to use for X? How to handle extra overhead due to encapsulation? [20:30:19] Q: You're just sending on a wire, that wire can handle 1500 bytes [20:30:45] Q: Do 1200, do 1000, to make sure there's room! [20:31:51] A: So the suggestion is to not pad hellos at all, and make sure they're smaller than N, and assume that the big data frames will make it [20:33:14] Eric Gray: drop the padding altogether [20:34:01] Radia: What do devices actually do to discover this value? [20:34:16] Eric: Is there a size that i can say can always get through? What is too big? [20:36:10] Q: In terms of encoding, all the states can fit into a 1500-byte frames, e.g., see GVRP. Some protocols rely on fixed frame size of 1500 bytes, don't make things complex [20:37:05] Russ White: ISIS Hello Padding is there to find MTU mismatches. If there is an MTU mismatch and you don't notice, it will simply blackhole a packet that is too big. [20:38:06] Don Fedyk: I agree that it's not a good idea to introduce two types of hellos [20:39:12] Don: The MTU was increased recently to account for encapsulation, e.g., MAC-in-MAC [20:40:21] Don: I recommend you keep the padding in there to ensure that the MTU difference is detected, but you shouldn't change IS-IS hello behavior [20:41:04] Radia: 2 reasons for hellos: loop prevention and link-stressing-MTU-difference-detection [20:41:33] Don: I don't see the need to change the IS-IS behavior. Don't mess with IS-IS. [20:42:24] Don Eastlake: You get a loop if the IS-IS adjacency doesn't form. [20:42:53] Don: That's not IS-IS behavior. [20:43:10] Radia: We're not going to create a protocol that sometimes has loops. [20:44:00] ?: You can encode the MTU in the hello like OSPF does [20:45:06] ?: Don't send packets bigger than 1500, put the real MTU in the TLV [20:46:01] Radia: You're saying that 2 hellos is more complicated than needed; have one hello, not padded, max size 1500, but put in a TLV that has the MTU [20:49:43] This conversation is going in circles, so I'm not going to scribe more of it for now. [20:51:41] Eric Gray: Are we talking about the big hellos growing to bigger than 1500? That would be a problem. [20:52:16] Don Eastlake: The Appointed Forwarders can grow large, so Don't Do That. Otherwise it will all fit in 1500. [20:52:25] Radia: It'd be nice to do the math to be sure. [20:53:35] ?: So the real reason for the padding is to deal with the hidden devices, and that's the criticial point. I really think that we need to have this protection. [20:54:08] Radia: So you're saying there is a value in testing the size rather than assuming that the ends know the MTU. [20:54:32] Russ White: If we're going to change the IS-IS packet format, it may behoove us to talk about that with the IS-IS WG [20:55:05] Radia: IS-IS may not care per se, since this is a trill-specific problem. [20:55:46] Russ: If we come to the conclusion that we're going to change the IS-IS hello, we should talk to the IS-IS WG about that. [20:57:02] ?: Legacy bridges in between may not handle 1500 bytes. Same situation exists in bridged network - you can drop GVRP, OAM, CFM, etc. IEEE is not worried about this problem, they assume that 1500 bytes pass on ethernet. We should not test the link, just assume that there is 1500 bytes, whether it's legacy or new devices. [20:57:43] Radia: Are you arguing that we should not worry about testing the MTU size, we should just assume it's 1500, and should not pad the hellos? [20:58:45] Erik: Clarifying question: IS-IS packets would be 1400-1500 bytes, data frames could be jumbo frames. IS-IS could do its job, then when you go send a jumbo frame, it gets dropped. [20:58:56] ?: Limit it to 1500 bytes, period. [20:59:07] Erik: If we are saying Trill can't use jumbo frames, that's just silly. [21:01:13] Luca: a little experience on this topic: when we designed pw forwarding plane in pwe3, we didn't have a way to check MTU. Quickly we found there are lots of little devices that shrink the MTU below 1500, results in web pages not loading etc. MTU TLV in the protocol - worked for a while, then people started doing virtual things - difficult to get the value for the MTU calculated correctly, so we fake it -- enter this value by configuration, which can easily break since the configuration doesn't necessarily reflect reality [21:01:47] Luca: Moral of the story, putting a TLV will likely result in faking the value. If you don't test it then you don't know it's right. [21:03:10] Erik: TRILL needs to have loop-safety, there's no debate on that. The only question is: Do we want to deal with intermediate devices that drop big frames? Do we want to deal with peers that have different MTU sizes? [21:03:39] Radia: That boils down to testing with padding vs. TLV [21:03:49] Radia: and if we have padding then we also need the small ones [21:05:27] Mark Townsley: Doesn't this just boil down to sending two hellos, one small, one big, because they discover two different types of information? [21:05:50] ?: Double the load of the CPU! [21:06:21] Don Eastlake: two polls. The first poll, how many for/against a TLV for what you believe the MTU is [21:06:46] ~12 for, ~1 against [21:07:01] The second poll, how many believe that at least some hellos should be padded [21:07:45] [I counted] ~9 for, ~6 against [21:08:43] The third poll, should there be one hello vs. two, assuming that all of these solutions prevent loops? [21:09:05] one hello: ~9; two hello: ~6 [21:10:01] Suggestion from the floor: one hello, one probe [21:11:02] Protocol draft changes: http://www3.ietf.org/proceedings/09mar/slides/trill-1.ppt [21:11:50] acassen joins the room [21:14:33] Q: These reserved groups [page 6], are they outer or inner addresses? [21:14:39] A: outer destination address [21:16:14] Want to talk about IETF Last Call, except we need to conclude the discussion about hellos [21:17:05] Erik: Frame types, encapsulation and ppp [21:19:08] http://www3.ietf.org/proceedings/09mar/slides/trill-5.pdf [21:19:35] acassen leaves the room [21:22:27] Q: Is there a customer requirement for TRILL over PPP? [21:22:33] A: PPP over SONET? [21:22:52] Radia: Maybe today we don't, but it's short-sighted to not consider that TRILL might go over other link types [21:23:05] Erik: Anything that doesn't have a MAC header that has a destination in it [21:23:53] Mark Townsley: You happen to have this magic moment where Jim, who is an expert in PPP, is interested and willing to write the spec: take advantage of it! PPP types end up elsewhere, like GRE, pseudowire headers, etc. [21:24:41] Radia: dangling discussion: can we get an NLPID? [21:25:45] Q: Oddly enough, the committee in charge of 9547 still meets. Feed into that group via T3's email list. [21:26:41] Comments from 802.1: http://ieee802.org/1/files/public/docs2009/liaison-to-trill-wg-0309.pdf [21:28:52] TRILL header options, http://www3.ietf.org/proceedings/09mar/slides/trill-2.ppt [21:31:56] Additional TRILL work: http://www3.ietf.org/proceedings/09mar/slides/trill-3.ppt [21:42:06] Anoop Ghanwani: TRILL OAM [21:43:26] IP, MPLS, 802.1 have e.g., ping, traceroute, etc. so TRILL probably does too [21:43:43] These messages are sourced and terminated at RBridges only [21:44:38] RBridge ping: trill frame from S-nick to D-nick with trill option saying it's a ping [21:45:40] RBridge traceroute: same but trill option saying it's a traceroute, all intermediate bridges respond [21:54:09] Goals and milestone update: http://www3.ietf.org/proceedings/09mar/slides/trill-6.pdf [22:09:06] Robert Raszuk leaves the room [22:13:41] Bill leaves the room: Computer went to sleep [22:25:43] nordmark leaves the room [23:05:59] Bill joins the room [23:15:33] Bill leaves the room: Computer went to sleep