Minutes: I-IS WG Meeting 11-17-2008 Document Status - WG Chair **************************************************** Preso 1 - Don Fedyk 802.1aq Shortest Path Bridging Overview Radia: Different regions have their own spanning tree algorithm? Don: Will be addressed later in the presentation. Dinesh: One source / bridge => limited by # of VLANs. Don: Yes. Ali: Encoding has source ID and VLAN ID. 4 K VID total in region. So somewhat fewer. Encoding has Source Tree ID, VLAN, and multipath . Dinesh: Single VID vs multiple trees? Don: If you have ECMP can map multiple VID to a given tree. Configuration based. Voice in the back ??: How many trees? Don: A tree/node => 200. Radia: More than 200 trees because of multipathing?? Don: Yes. Radia: Does the 200 include the multipath. Don: No - 200 * the number of paths. Eric:: 200 is arbitrary limitation based on study of scalability - not a hard limit. ********************************************************** Preso 2 - RBridges/Trill and IS-IS Donald Eastlake Ross: If routers attached to LANs where Rbridges are also attached will they ignore each other? Don: Routers look like end stations to Rbridges. Better to have all Rbridges. Dino: Drawing misleading if Rbridges participate in spanning tree. Don: Rbridge don't particpate in spanning tree in the normal sense of the word. Eric: Processing IS-IS frames just for L2 or also L3 IS-IS frames? Don: Only L2 IS-IS frames. Igor: How does L2 frame get to bridge (agnostic of TRILL) Don: Separate campuses must go through routers. Within a campus normal inter-bridge traffic. Ali: How is forwarding done in Rbridge campus? Don: Described in base TRILL spec. Dinesh: Bridges connected by rbridges - essentially a layered approach - inter-rbridge forwarding - then mapping back to straight L2 forwarding. Don: Rbridges are seen as customer devices - not provider device. Eric: "Customer" used loosely. A customer could be a provider. Don F: Provider bridges are just another layer of hierarchy. Ali: Customers "tag" /VLANs. ************************************************************ Preso #3: Carrying Attached Addresses in IS-IS for L2 Systems Ayan Banerjee Russ: Likely to be changes in the draft to support 1.aq Dave: Goal to have "kitchen-sink" document - act as place for all L2 extensions. Eric: Why do you need a separate PDU? New advertisements are not changing topology. Ayan: Could trigger unnecessary SPFs. Eric: MAC address do not trigger SPF? Ayan: Yes they do. This is reachability for end stations of campus. Tony: Difference of changes of location of end station MAC addresses do not requires full SPF. Eric: What does extra PDU buy you? Tony: Achieve separation of SPF from non-SPF affecting. Why not do this for unicast MAC addresses as well? Tony: Why only 256 fragments? Dino: Jumbo frames cna provide 6x. Tony: Jumbo frames "not supported". Trade jumbo frames for TLVs? Dave: Original version of the draft is "long in the tooth" and has expired. Would like this to become kitchen sink draft. Eric: Consider not using MGROUP PDU - change it to be reachability PDU. So all advertisements which don't trigger SPF could go into new PDU. It is not multicast vs unicast - it is topology change vs reachability change. Dino: Multicast changes occur more frequently. Eric: Mobility may be important. Ayan: Can do incremental SPF. Dave: Not yet WG document. Both TRILL and IEEE .aq Anyone opposed to making this a WG document? (No hands raised.) Should this work be completed? (Many hands raised.) Need to work w ISO liason issues.