[rbridge] Draft Trill Minutes for IETF66
stbryant at cisco.com
Mon Jul 24 10:52:35 PDT 2006
TRILL Working Group
TRansparent Interconnection of Lots of Links
IETF-66 (Montreal), 1300-1500, Monday 25th July
Administrativia (scribe etc), Agenda, Chairs
Charter milestones Chairs
o Completed base protocol spec as WG document.
o Accepted problem statement and applicability as WG
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
Problem and Applicability Statement
draft-ietf-trill-prob-00.txt, Joe Touch, Radia Perlman
Changes since last IETF diagram cleanup, scale
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.
Multiple spanning tree not needed
No answer on whether regions were needed.
Some addresses not forwarded - BPU, 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?
Chair: how many have read doc?
Doe any have an opinion as to usefullness 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
Yaakov Stein: Once again, this is another statement of
the fact that we need a good statement at the front of the doc.
The Architecture of an RBridge Solution to TRILL
draft-gray-trill-rbridge-arch-01.txt, Eric Gray
Changes to draft: remove 2119 standards language from
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 encap tunnels (Domain)
Shows very complex and colorful slide
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 desginated RBridge clarified. There is always a
Still need to discuss - need "pseudo-node" use ?
Is this too detailed for architectures?
Should we remove distinctins between hubs, switches
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
Stewart: IEEE people have said that RBridge needs to address,
otherwise 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: ccept as WG doc?
Chair: how many have read?
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, Joe Touch
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 differnt kinds of IS-IS packets
(L3 IS-IS, RBridge IS-IS core instance, desginated
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
bit as hierarchy shouldn't be needed
Shahram: Is there a field for OAM packets?
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 Ethertype for MPLS
Yaakov S: IETF asked ITU NOT to use a separate Ethertype
Dino: Takes opposite view + says may need to use PRI to
do L2 QOS - may be problems with RBRIDGE and MPSL traffic
on same LAN
Mark T: probably want to keep different, 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
Radia: good reason to use priority field but don't
need to prune the flood.
per VLAN packets: endnodes and multicast receivers for
decided to differentiate, so need 3 different multicast addresses
1) Ordinary data
2) Core IS-IS RB instances
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
Radio 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
Multicast Address Assignment for Standards
Donald Eastlake 3rd
Chair: need to request multicast address from IEEE
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 ISIS - why whould
they allocate a block for this
Radia: Would any company with an OUI donate one
Chair: Also need an Ethertype.
TRILL Routing Requirements in Support of Rbridges
draft-gray-trill-routing-reqs-01.txt, Eric Gray
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? (somewhat asked for this)
- Obtain address prefix for IS-IS (in order to make it
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
More information about the rbridge