[rbridge] Draft Trill Minutes for IETF66

[Stewart Bryant]

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
  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



Problem and Applicability Statement
draft-ietf-trill-prob-00.txt, Joe Touch, Radia Perlman

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.
  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?
  (Silence)
  Chair: how many have read doc?
  Answer: 7-8
  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
  (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.



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
  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 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
  designated RBridge.
Still need to discuss - need "pseudo-node" use ?
Is this too detailed for architectures?
Should we remove distinctins 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
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?
  (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, 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
   for T-MPLS
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
   prioritization.
Radia: good reason to use priority field but don't
   need to prune the flood.
   per VLAN packets: endnodes 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
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
rhyming abstracts



Multicast Address Assignment for Standards
Donald Eastlake 3rd

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 ISIS - why whould
  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

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
  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