TRILL Working Group TRansparent Interconnection of Lots of Links IETF-66 (Montreal), 1300-1500, Monday 25th July Minutes by Stewart Bryant with some notes by Mark Townsley integrated, edited by Donald Eastlake. Administrativia (scribe etc), Agenda, Chairs Donald Eastlake announced that he would be chairing the meeting alone, as Erik Nordmark was in Sweden for family business. Donald indicated he would make a brief presentation on assignment of multicast MAC addresses for standards purposes right after the base protocol document specification. There were no other changes in the Agenda. Charter milestones were discussed: o Completed base protocol spec as WG document. o Accepted problem statement and applicability as WG work item. o Expect to start work with routing area WGs on TRILL extensions by July o One year from now work should be completed and will need to recharter or hibernate Problem and Applicability Statement draft-ietf-trill-prob-00.txt, Joe Touch presenting (See also slides.) Changes since last IETF: diagram cleanup, scale estimates Not intended to scale beyond large bridge deployments but may be able to do so. Which version of Ethernet is baseline for Trill? 802.1D. Need to support transport of VLANs. Try hard to avoid duplication and maintain in order delivery, but do not need to be unconditionally achieved. Both of these are a SHOULD. Multiple spanning tree not needed No answer on whether regions were needed. Some MAC addresses not forwarded - BPDU, Pause, Other bridge specific addresses - we are not sure what to do but must make a statement in each case - solution must be carefully considered. Next step - summary of problem statement and requirements Address remaining notes in doc Target - final revision by end of July LC early August and then forward to IESG Mailing list has been silent - please discuss on list. Is this document useful? (Silence) Chair: how many have read doc? Answer: 7-8 Doe any have an opinion as to usefulness of doc? (Silence) bring to list. Joe Touch: Give such lack of feedback that hard to know what to do. Andy Malis: I read and saw a history of Ethernet, but didn't understand the applications for TRILL. Joe Touch: Not sure, except to say when STP is a problem (in draft) Yaakov Stein: Once again, this is another statement of the fact that we need a good statement at the front of the doc. Donald: There should be a bulletized executive summary up front. The Architecture of an RBridge Solution to TRILL draft-gray-trill-rbridge-arch-01.txt, Eric Gray presenting (See also slides.) Changes to draft: remove 2119 standards language from informational draft Intro has been expanded, definitions clarified, Removed options and aligned with protocol spec, removed references to "campus" Added clarifying examples Intro includes text on "strategy" Definitions have been changed. Campus replaced with "CRED" CRED - co-op Rbridge and encapsulation tunnels (Domain) Shows very complex and colorful slides, should help wake up the audience. Is this a "campus"? No-one considers a campus to extend beyond the "domain" but does it include the routers? Now CRED has all cooperating RBridges. When there are several paths between RBridges, STP would shut down, but this would lose BW Role of designated RBridge clarified. There is always a designated RBridge. Still need to discuss - need "pseudo-node", which is defined more clearly. But pseudo-node is kind of protocol specific. Is this too detailed for architectures? Should we remove distinctions between hubs, switches and bridges? Need a better security statement, even though not a normative doc. But don't want too much to be configured Stewart: The wiring closet problem. Is this still an issue? Eric: There was a discussion of this. Concluded that one way to fix it is an implementation with an internal bridge configured as root. Further discussion would be good. Stewart: IEEE people have said that RBridge needs to address, otherwise it is inferior to existing implementation Eric: Need to discuss how to solve. Radia: Maybe not solvable. Eric: That would be nice to know too. Stewart: Need to admit if can't be solved. Eric: Need more comments Eric: accept as WG doc? Chair: how many have read? (very few) Of those who have read - how many for and against? (2 yeses) Jon opposes just for it to be 2:1 rather than 2:0 Rbridges: Base Protocol Specification draft-ietf-trill-rbridge-protocol-00.txt, Radia Perlman presenting (See also slides.) A few minor things left to do. Fold in Stewart's draft using MPLS-like header (4 bytes) rather than 6 byte header originally proposed for this we need to use nicknames Also there are 3 different kinds of IS-IS packets (L3 IS-IS, RBridge IS-IS core instance, designated RBridges per VLAN) First and third type are forwarded by RBridges, second type always consumed Shim header has 19-bit label + 1-bit specifying if ingress or egress RBridge MPLS header has EXP and S bits, but never need S (bottom of stack) bit as hierarchy shouldn't be needed Shahram: Is there a field to indicate OAM packets? (Operation and Management) Radia: not at the moment Radia: can use BFD if needed Dino: Is there a new Ethertype? Radia: yes need a new one. Radia: should we reserve fields in MPLS label (e.g. priority, S-bit) or define them? Radia: we probably do not want to use the Ethertype for MPLS Yaakov S: IETF asked ITU NOT to use a separate Ethertype for T-MPLS Dino: Takes opposite view + says may need to use PRI (priority) to do L2 QOS - may be problems with RBRIDGE and MPSL traffic on same LAN Mark T: probably want to keep different Ethertypes, but that reduces the utility of existing hardware Radia: Regular L3 IS-IS packet just like normal traffic (what about OSPF?) Dino: IS-IS needle in a haystack but may need prioritization. Radia: good reason to use priority field but don't need to prune the flood. per VLAN packets: end nodes and multicast receivers for IGMP-joined groups decided to differentiate, so need 3 different multicast addresses 1) Ordinary data 2) Core IS-IS RB instances 3)VLAN case shows format (for core instance payload is entire IS-IS packet as emitted) core instance is generated by RBridges, so there is an IS-IS packet without Ethernet header Per VLAN: also don't need inner layer 2 header, but need VLAN tag (+ align to 16 bits) - everything is in the outer header Outer header is for classical bridges to function correctly Radia asks if this is OK. New algorhyme written by Radia's son (Ray) (written in 1 hour) Radia suggests that the poem should be the abstract to the spec and furthermore, that all RFCs should have rhyming abstracts. Multicast Address Assignment for Standards, Donald Eastlake 3rd presenting (See also slides.) Chair: need to request multicast address from IEEE registration authority Should we request a small block? Donald Eastlake plans to meet (informally) with 802.1 chair Tony Jeffree to discuss 802.11s multicast addresses he will bring up TRILL requirements Dino: Allocated two to ISO for IS-IS - why would they allocate a block for this Radia: Would any company with an OUI donate one multicast address? Chair: Also need an Ethertype. TRILL Routing Requirements in Support of Rbridges draft-gray-trill-routing-reqs-01.txt, Eric Gray presenting (See also slides.) There have been changes after detailed view. - Clarified purpose of document and importance of multicast - Reduced size of sections 3 and 4.2 - Candidate routing protocol requirements - Security section somewhat expanded - Purpose - why we want a routing protocol for multicast? - Still need to discuss - STP termination (need to clarify or remove) - Need to number requirements? (someone asked for this) - Obtain address prefix for IS-IS (in order to make it configuration-free) Radia: Area address needs to be zero. Eric: may be reserved. Dino: need to specify size of address Radia: Could be one byte area address Eric: For the variant of ISIS that trill uses - what NSAPs should be used? Dino: no longer a body that does NSAP address allocation so group should do it. Dino: doesn't matter since different transport Eric: need one more round of editing - please send comments Eric: Can we accept as a WG document? Chair : How many have read the draft? 3-4 Chair: anyone want to bring up anything else? Mark: lot of people in room - please participate. Jon Zwiebel: How is multicast traffic handled? Radia: explains - PIM & IGMP snooping - text needs to be read and reviewed Dino: haven't seen anyone implementing Chair: yes please tell mailing list if implement - otherwise this will all die Dino: have you polled the list? Chair: not explicitly, but have heard large companies mention customer demand