TRILL Working Group meeting, 24 March 2009.

Chairs welcomed participants, reminded participants of the note well and patent requirements, and obtained volunteers for jabber scribe (Bill Fenner, Arista Networks) and note taker (Dorothy Stanley, Aruba Networks). [Minutes have been edited by the Chairs.]

Chairs reviewed the agenda and asked for changes. No changes. Agenda is as follows:

TUESDAY, 1300-1500, Room: Imperial B
  5 min.  Administrativia (scribes etc), Agenda Bashing, Chairs
 15 min.  Review of Existing Charter, Milestones, and Document Status,
              Chairs
         Rbridges: Base Protocol Specification
         draft-ietf-trill-rbridge-protocol-12, Radia Perlman, Donald Eastlake,
              Silvano Gai, Dinesh Dutt, Anoop Ghanwani 
 10 min. Implementation Experience: Two kinds of Hello, Radia Perlman
 15 min. Changes from -10 to -12, Donald Eastlake
 10 min. Frame types, encapsulation, and PPP, Erik Nordmark
 10 min. IEEE 802.1 comments on the TRILL protocol specification
         draft, Don Fedyk
 10 min. TRILL Header Options: ECN, VLAN Promotion
         draft-eastlake-trill-rbridge-options-02.txt
              Donald Eastlake, Caitlin Bestler
 15 min. Additional TRILL Work/Documents, Donald Eastlake
     [Although not on the original agenda, a presentation on OAM by Anoop
      Ghanwani was given at this point in the actual agenda.]
 10 min. Charter Update, Chairs

WG Document status

- TRILL: Problem and Applicability Statement, draft-ietf-trill-prob-06
  	 o IETF Last Call complete (version -05)
  	 o Resolving AD Discusses and Comments [subsequent to the TRILL WG meeting but during the IETF meeting, all AD Discusses were cleared]

- The Architecture of an RBridge Solution to TRILL, draft-ietf-trill-rbridge-arch-05
	o Timed out and in the opinion of the chairs should be dropped at this point. Chairs called for any objections and there were none at the meeting.

- RBridges: Base Protocol Specification, draft-ietf-trill-rbridge-protocol-12
  	o WG Last Call comments substantially resolved
	o IEEE 802.1 WG was asked to comment on the draft regarding its effect on the Ethernet service model. Their response has been received.
        o Planned to be reviewed by IETF Experts: Bernard Aboba and Dan Romascanu

- VLAN Mapping, draft-trill-rbridge-vlan-mapping-00
        o Ready for WG Last Call? Are there people willing to commit to reviewing the document before a WGLC? Have volunteers: Silvano Gai, Anoop Ghanwani, Luca Martin.
	o Agreement in the room to do a 3-week WG Last Call

- Liaison sent to IEEE 802.1 Working Group and Donald Eastlake attended a meeting of the IEEE 802.1 Interworking Task Group in January 2009. An update message was sent to 802.1 when the -10 draft was updated to -11.
	o IEEE 802.1's response is at: http://ieee802.org/1/files/public/docs2009/liaison-to-trill-wg-0309.pdf

Review of relevant non-TRILL WG Drafts
- IS-IS Extensions for Layer 2 Systems, draft-ietf-isis-layer2-00.txt. Document created by merging 2 documents: draft-eastlake-trill-rbridge-isis and draft-ward-l2isis. Needs further work.
- RBridges: TRILL Header Options, draft-eastlake-trill-rbridge-options-02.txt
- RBridges: Notes, draft-eastlake-trill-rbridge-notes-01.txt

Two Kinds of "Hellos" - Radia Perlman
- 2 RBridges not seeing each other's "hellos" is BAD as it produces loops.
- Problem: IS-IS pads Hellos to "maximum size", to be assured that such frames do indeed make it through
- Two reasons for a hello - see how big a frame really works - Send big frames. Make sure you hear all other DRB candidates - send little hello.
- Agreed to send two types of Hellos, "Protective" little ones and "Adjacency" big ones. 
- Which Hellos, which VLANS - same VLANs as before for the little ones. Everyone configured with one VLAN they want to be the Designated VLAN - can specify it if DRB.  Radia describes the rules for sending big and little hellos. 
- Why is the big hello needed? Information included that is not in the little hello, e.g. VLANs for which I am the forwarder. Don't want to have loops. 
- Two frames adds a lot of complexity. Easier to have a rule of "never send more than "x" bytes".
- 1500 bytes is always supported.
- A wire can have bridges on it, which can add tags and/or have more limited MTU. 
- Make it 1000 bytes, and have plenty of space. 
- Make this simpler, and don't pad the hello, say it can't be any bigger than a certain amount. 
- Any hello, big or little resets the holding time.
- Notion of big and small is rather vague. Just need to know "how big is too big". There are ways to do this. Can minimally use configuration. "Too big" means it won't get through.  Discovery protocols. 
- Take out the padding for TRILL. 
- VLANs can be encoded in 1500 byte frames, IEEE MVRP - relies on max frame size. Use that precedent.
- IS-IS hello padding is there, don't want to build adjacency if there are different MTU sizes. E.g. GigEthernet  on one side and not on the other, with jumbo frames.
- 802.3 frame has been expanded to account for tags at the Ethernet layer. Going with fixed 1500 should work. SNAP, VLAN headers accounted for.
- 2 reasons for hellos - one for IS-IS padding - testing/stressing the link, But if hellos don't get through, problem.
- Don't see a need for the IS-IS behavior in the bridging environment. 
- Jim Carlson built an implementation, and had loop. Legacy equipment in the middle with limited MTU lead to a loop. In routers, only forward if there is an adjacency. Here, can forward [actually encapsulate/decapsualte] if there isn't an adjacency.
- Reconsider using 2 hellos, but padding is one way - OSPF used an MTU. Having padding minimized the trust level needed. Don't want to complicate the common case. On Ethernet, have support for 1500. Add a TLV, to go up from there to preserve MTU detection. 
- Support having fixed 1500 level. Also consider 1280.
- Any Ethernet medium shall guarantee 1500 byte payload. All manipulation is on the header. Might drop frames because of the VLAN tag. All devices that send with a VLAN tag - hadn't increased the frame size.  Don't want the complexity of 2 types, use 1400 instead.  Failure behavior is a loop - really bad. If data frames are dropped, not as bad. 
- Do we need to pad hellos?
- Goal is to eliminate looping, dropped data frames is secondary. 
- If have the larger MTU, tweek it down to a lower value. Might a hello be bigger than 1500? One field is the appointed forwarders - don't have a large list. 
- Real reason for padding is to deal with hidden devices.  Need to have this protection. The "mixed media" is "old" and "new" devices. A lot of equipment doesn't take into account the expansion due to VLAN headers. There is value to testing the size.
- If we are going to change the IS-IS packet format, may want to take it to IS-IS rather than here. In IS-IS, impact doesn't matter, just won't use the link. For TRILL, it's a bigger issue. Case can be made to IS-IS to change the length, add a TLV.
- Legacy bridges may not handle 1500 bytes plus tags. Same situation occurs in a bridges network. Drop MMRP, etc. messages. In IEEE, they assume that 1500 bytes get passed on an Ethernet link. Arguing that we should not test the link. 
- TRILL requires loop avoidance. Should hellos be padded to the maximum size? Should we have a mechanism to pad & test? Or just a TLV? If have pad & test, then need short hellos.
- Need short hellos for loop safety. If pad to a known amount that always works, say 1400 bytes, then you haven't learned anything. 
- Chair took straw polls: 
o We should add a TLV (what you believe the MTU is) (12 yes, 1 no)
o At least some hellos should be padded to the MTU? (8 yes, 8 no)
o There should be one or two hellos? 10 (one) 6 (two)
- Could have a hello and a "probe".

Changes from [Base Protocol Specification] -10 to -12
- Chair summarized Distribution Trees related changes.
- Chair summarized other IS-IS related changes.
- Chair summarized security and IANA considerations
- Chair summarized Editorial changes
- Is the base protocol specification draft ready for IETF last call in paralled with IETF expert review? Not yet. Need to resolve the hello issue on the list first.

Presentation on TRILL over PPP
- Issue - How to tell L3 IS-IS frames apart form TRILL IS-IS frames? On Ethernet, we use different (multicast) destination addresses; Can't be applied to PPP or other media without an outer destination address.
- Use a separate NLPID. Can we get one? Checking, believe can get from IANA, more investigation needed. JTC committee, T3 meets on an e-mail list. Appears that we select and use the number, and notify the appropriate parties. 
- Jim Carlson will write a draft on how to do this. 

Discussion on received IEEE 802.1 Comments
- Treat these just as comments received on the mailing list.
- Brief Summary: "802.1" referred to in the protocol specification is a subset of 802.1-2005, not 802.1Q. Also note about no guarantee of being compatible with future amendments to 802.1Q.
- Draft will be updated to clarify these areas.

Discussion on document describing the options available in TRILL.
- This document provides more details than the base protocol specification and specifies some particular options. Two options have been added:
o ECN Bit Option
o VLAN Promotion TLV Option

Future TRILL Work
- Consider the following when selecting future work: Is the item important/high value? Is the item urgent/time sensitive? Does anyone want to work on it?
- Management (MIB) work - have had a lack of volunteers to date
- TRILL over PPP - Different frame encoding needed on PPP or other media without an external destination MAC address. Have a volunteer
- 802.1 features - port level
  	o 802.1Qaz - enhanced transmission selection - output queue enhancements
	o 802.1Qbb - Priority based Flow Control - is hop-by-hop, is in port logic, allocated to 802.1Q.
       o 802.1X-REV
- 802.1Qau - L2 method to rate limit flows causing congestion
- OAM/Connectivity Fault Management - 802.1ag-2007
- Provider Bridges, Provider Backbone Bridges - currently out of scope for the current TRILL effort. 
- ARP, Neighbor Discovery optimization - carved out initially, targeted towards a separate document. Comment: don't do this, keep L2 and L3 separate. Ethernet supports a multi-protocol environment.

Presentation by Anoop Ghanwani on TRILL OAM
- Tools for debugging and detection of mis-configuration, e.g. IP has ping and traceroute
- RBridge ping/traceroute messages are originated and terminated at RBridges. Cannot be done at a non-TRILL aware device.
- Description of RBridge ping. 
- Description of RBridge traceroute.
- Agree that this work needs to be done, that the problem needs to be addressed. Need to think about the solution approach.
- Why is traceroute needed? Don't have host to host. Have link state info. 
- Need to verify that the control plane and data plane paths are ok. Is it worth protecting from severe equipment failures?
- Need to be able to troubleshoot equipment, debug the equipment. 
- Have info in the forwarding databases. 

Review of TRILL Goals and Milestones
- Architecture Document - will ask on the list if there are any objections to dropping this
- We need a MIB, first step will be to study existing IS-IS MIB and bridge MIB
- Review of proposed new milestones

Meeting Adjourned, 3:09pm