TRILL Working Group Minutes
Chairs: Erik Nordmark (Cisco), Donald Eastlake 3rd (Huawei)
Secretary: Jon Hudson (Brocade)

Date:  Tuesday, July 30, 2013
Facility: Intercontinental Hotel, Berlin, Germany
Room:  Charlottenburg 2/3
Time:  17:00 - 18:30
Minutes by Donald Eastlake, Erik Nordmark, and Jon Hudson

[Note: the times given with the major items below were the times
originally scheduled, not the amount of time actually taken.

 5 min.  Administrativia (scribes etc.), Agenda Bashing, Chairs
===============================================================

Blue sheets sent around. Self-introductions by Co-Chairs.

Donald Eastlake (Huawei, Co-Chair): Last IETF meeting we asked for two
hours and got three. This time we asked for two hours and got 90
minutes.

New Note Well shown and described with reference to BCPs.

Secretary Jon Hudson (Brocade) introduced. Tal Mizrahi (Marvell)
volunteers as jabber scribe.

Agenda reviewed for bashing. No changes requested.

15 min.  Document Status, Charter Revision,
         Review of Milestones, Chairs
===========================================

Donald: [See slides] Document status reviewed. 9 RFCs. 5 drafts in RFC
Editor's queue held up by dependencies. 1 draft through IETF Last Call
in the IESG. Two documents past WG Last Call for which the request for
RFC publication should be submitted shortly.

One draft in WG Last Call: draft-ietf-trill-rfc6327bis, updates RFC to
cover non-Ethernet links, point-to-point links, and integrate BFD
support.  Notice of this TRILL WG Last Call was also posted to the
ISIS WG list. Since I am a co-author, Erik should check on the status.

Erik Nordmark (Cisco, Co-Chair): There have not been very many
comments on the list. How many people have read this? [several] How
was the draft?

Comment from someone in the audience: "It is beautiful!" [Some
laughter]

Erik: We should be sure that is recorded in the minutes.

Donald: The person at Cisco who is implementing this [Howard Yang] has
commented on the list and his comments have been incorporated in the
draft.

Erik: Well, we will do this on the list also but I think we have
enough to declare WG consensus for the document in its current form
with the edits that have been done.

Donald: Status of other documents: The draft-ietf-trill-cmt relates to
active-active and has expired but it can be re-activated when that
work item is added to the Charter. OAM Fault Management will be
presented later in this meeting. Finally, there is the mapping draft
that has not been worked on much by the WG recently. Please read the
drafts. There is one draft related to TRILL in another WG which is
draft-ietf-isis-rfc6326bis that is in last call in that WG.

Donald: Charter Revision: was presented as the March meeting and has
been discussed on the mailing list. It has gone through IESG Internal
Review - they mostly made editorial changes so that some items were
made more specific but did not add or delete any work items. Has now
been publicly posted.

Donald: Milestones: Most of our milestones are completed. We have one
past due. Only a few milestones left. Milestones need to be updated
but, since a new Charter is in process, our idea is to wait until the
Charter decision is made and then post proposed milestone updates to
the list.

Donald: One more slide, there was a successful TRILL plugfest at the
University of New Hampshire InterOperability Laboratory (UNH
IOL). Some minor glitches as usual but the TRILL switches from three
different switch manufacturers were look-up in various ways and
successfully interoperated at the control and data planes including
adapting to reconfigurations and induced failures. Tests included lots
of details such as address learning/forgetting, TTL decrement,
distribution tree construction, etc. Extreme Networks and Huawei were
two of the three. Permission has not been received by the third to
announce who they were but it is expected any day now. Ixia was
involved in the plugfest as a test equipment manufacturer.

Sam Aldrin (Huawei): There is a Charter item to write an
implementation report?

Donald: Yes, there is, and I think it should talk about implementation
and deployment. One would expect the White Paper from this plugfest as
well as the already released material from the plugfest last November
and the Press Release from the plugfest before that to be input to
such a report.

Sam: So, the WG will be doing this report?

Donald: Yes. Plugfests or interoperability tests are not actually done
or sponsored by the IETF. These plugfests and White Papers are all
from UNH IOL and to participate you have to sign a non-disclosure
agreement so you can say that you participated but you can't say
anything about anyone else without permission from them or from UNH
IOL. Our report will presumably be an Internet-Draft and might get
published as an RFC.

Erik: The White Paper might not mention specific areas of ambiguity or
the like.

Donald: Well, the White Paper mentioned peculiar behaviors. The
ambiguities discovered by the very first plugfest were fixed by the
draft-ietf-trill-clear-correct draft now in the RFC Editor's
queue. For the 2nd plugfest, two documents were issues. A Press
Release and a separate white paper covering specific ambiguities. But
this time it seems more like implementation glitches than ambiguities,
as I remember it. UNH IOL has a TRILL test plan that I think is
public and appears to be working towards a TRILL certification
test. Their test plan was modified based on the plug fest.

Tim Winters (UNH IOL): We take the standard and we put out documents
that anyone can download. For the earlier plugfests did find
disagreement about what the standard meant but this time there was
little of that. The main marketing involvement with the White Paper is
just getting permission to list a company as a participant. The White
Papers are quite technical. Press Releases are a different matter.

Tissa Senevirathne (Cisco): We should not confuse the Implementation
Report, which is more generic, with the technical details of these
White Papers.

Donald: Yes, I was just trying to say that the White Papers could
provide some piece of input of the Implementation Report.

30 min.  TRILL OAM, Tissa Senevirathne, Tal Mizrahi
===================================================
         draft-ietf-trill-oam-fm-00
         draft-mizrahi-trill-loss-delay-01
	 draft-deepak-trill-oam-mib-00

Tissa Senevirathne (Cisco): [Presentation, see slides] ... Status
update on documents and what has been accomplished ... We are
significantly behind the time line that was announced at the Vancouver
meeting and will say have we a plan to get closer to that schedule ...
Will go over just the changes in the fault management document but
will talk more about the MIB document because it is new. ... We have
added a "base mode" to fault management to reduce configuration for
the default. ... Application of CCM message to TRILL including
multi-path ... Report the first path that fails and next path that
works ...

X: How long do you keep that data?

Tissa: An implementation decision but there is no prescribed timeout.

Erik: Well, if you have already sent an SNMP trap, as you say, then
you could throw it away, unless you need it to include in the MIB?

Tissa: Exactly, it is included in the MIB. ... Please read section
12.1 in the Fault Management draft.

X: Is there a time stamp?

Tissa: There is no time stamp in the CCM protocol per se. But that
sounds like a good suggestion. ... We will talk about next steps after
all the drafts.

Tissa: [MIB Presentation, see slides], Deepak could not make it to
this meeting. But it is a very important draft because it is the glue
to hold together different OAMs and it uses a standard augments
technique. So whatever is in the IEEE MIB stays there but the IETF
TRILL MIB has additions using augments. We can implement what TRILL
needs and continue to use the elements defined by IEEE. This is a
standard technique used by ITU and MEF. ... The MIB is important to
interoperability. ... Any questions?

Sam: I have a few questions. Are you enabling write options on the
MIB?

Tissa: Yes, because you need to configure the flows such as the flow
entropy.

Sam: But very few MIBs have write options these days. The MIB Doctors
may object. It is not common in the IETF.

Tissa: But it's in the IEEE MIB. I am not a MIB person myself.

Sam: For example, in MPLS, we were told no more write options in MIBs.

Thomas Narten (IBM): I don't think it is a simple "yes" "no" question.

Donald: There is a trend against writable MIBs.

Sam: The trend is that if you need to write configuration go to
NETCONF or the XML model, not MIBs.

Tissa: I think this is different because there is no XML option in the
IEEE configuration that I know of but I'll look into it.

Sam: The third comment I have is, do I need to implement CFM in order
to have TRILL FM (and its MIB)?

Tissa: Sure.

Erik: I guess I don't understand how this augments thing works. The
way you described it is seems like a compiler include. You get the
whole original MIB plus what you have added. I may have this wrong but
the whole MIB would show up in the IETF MIB tree right? Or are you
just referring to the stuff in the IEEE MIB tree?

Tissa: What happens is that you have the IEEE MIB and at some point
your divert into the IETF MIB.

Margaret Wasserman (Painless-Security): It doesn't change OIDs. I can
explain it. When you have a table, augments adds new columns with the
same keys. But those new columns would be numbers in the IETF part of
the tree but the other columns would still be numbered in the IEEE
part of the tree but, conceptually, they would all be columns in the
same table. We are just adding columns. But you do have to implement
the other MIB because otherwise the table wouldn't even exist.

Sam: That means than any instance of the table will have these
additional columns. If a vendor chooses not to implement CFM...

Tissa: But things like the counters all make sense for TRILL. You have
to implement a TRILL backend, of course. You can't just implement CFM
and have support for TRILL.

Erik: It may be useful to clarify all this in the document.

Tissa: We can do that. But remember that the base state machine is the
same for TRILL as for CFM. There may be some CFM paths you don't
implement. But the core is CFM.

Margaret: Optional and mandatory columns in a table can exist in the
base MIB and don't need augments. Some generic tools might not
understand augments. So that might not be the best way to do
it. Possible to instead have a separate table in TRILL with an
explicit OID reference to the table in the table entry in the CFM MIB.

Tissa: Margaret, I will connect Deepak with you and maybe we can work
this out off line.

Margaret: OK. I've written a lot of MIBs.

Donald: My condolences.

Sam: Using augments makes thing more complex.

Margaret: The reason to push back on writable MIBs is that they don't
get implemented. If you can show that the CFM MIB is widely
implemented as writable then there is a good argument this this will
be implemented to configure the same tools. We still do writable MIBs
for DOCSIS because they really use writeable MIBs. If you are going to
have a writeable MIB, there is a way to write a conformance statement
so you have two levels of compliance: for read-only and writable.

Naveen Nimmu (Broadcom): If we are re-using CFM MIBs, how are fields
not applicable to TRILL interpreted?

Tissa: We'll look into that.

Donald: This is running a bit long, I'd like to cut this off shortly.

John Pellisier (?): On thing you might consider, augments means IEEE
could pull out the rug if they change the MIB.

Donald: MIBs don't change.

Pat Thaler (Broadcom): Objects don't disappear. That's a rule of
MIBs. Even if we find a serious error, they are deprecated and a new
one created in a new module. So this is not an issue.

Tissa: Thanks for all the interesting comments.

Performance monitoring
======================

Tal Mizrahi (Marvell): [Presentation, see slides] This was presented
at last IETF, so will just go over the highlights this time. Read the
draft for more details. ... loss/delay measurement ... one/two way
... pack formats the same as Y.1731 ... The authors believe it is
ready for WG adoption.

Sam: I've talked to Tal already, so this is really a question for the
WG. Do you really want to only do this for synthetic traffic? Or
also packet loss etc. for user traffic?

Tal: Both options are available in Y1731. The main motivation in going
for synthetic here is that in TRILL you can have broadcast or unknown
unicast or pruned multicast. So you can have inconsistent counts due
to replication. If the WG wants to do it based on user traffic as
well, we need to consider if that is possible.

Erik: Is the issue that if I do this on user data it would get
numbered at one MEP but is a mixture of different kinds of traffic,
some unicast, some other, so it would be hard to tell just what the
count at other MEPs means? ...

Linda Dunbar (Huawei): Synthetic data is OK but your counts can be
off. Link aggregation and ECMP can affect buffering encountered along
different paths and change loss rate.

Tal: But the flow entropy solves that by fixing the path followed to
mimic the path of user data...

Linda: But you can't do that if you use synthetic data. It can depend
on the header and different hashing on different nodes. Cannot
guarantee that user data goes through a particular path.

Erik: If it just depends on the header, the entropy will take care of
that. But it could depend on other things like packet size. So actual
user data could have different size distribution. Entropy is not
perfect but tries to cover ECMP part of this.

X: What would be useful if you have multiple links to avoid mismatch
better to send synthetic data on all links hop-by-hop. ... Similar to
MPLS OAM right?

Donald: We are getting short on time for this part of the session. It
is a hard problem and depends on exactly what you are trying to
measure. People are welcome to post about this on the mailing list. I
don't think we will hash all this out here.

Tissa: Yes, we need to weigh the benefits versus the complexity. I
think it is a good idea to discuss on the mailing list.

Tal: Thanks.

Next steps
==========

Tissa: Going back to next steps for OAM: Need reviews of Fault
Management by IEEE and any other appropriate SDOs. So this is a
request to the Chairs to send a formal Liaison to IEEE about this.

Donald: Sure, if there is consensus to do it in the WG, we can send a
Liaison to Tony Jeffries, Chair of IEEE 802.1, asking for review of
the fault management draft or of the fault management and framework
drafts.

Thomas: I think this is a fine thing to do. But we must be clear as to
the status of the documents and what kind of review we are expecting.
For example, are we expecting this to be the only review or will there
be other checkpoints later? We should understand the whole process.

Donald: When you send a liaison and expect a written response back,
this is not typically a speedy process. It is not clear that we would
get that before WG Last Call or whatever. We should indicate that
informal responses would also be appreciated.

Thomas: Are we expecting a formal response?

Donald: If we send a written liaison asking for review, I think we
should be expecting a written response from a meeting of IEEE
802.1. Hopefully we will also get a lot of informal feedback.

Thomas: Discussion of the liaison wording would be good

Donald: We'll send it to the WG mailing list before sending it to
802.1.

Tissa: Next step on performance management is WG adoption. Can discuss
on the list. Next step on MIB is incorporate the feedback from this
meeting. I don't know if I am being aggressive but it would be good to
incorporate feedback from SDOs by the November IETF meeting.

Erik: By SDOs you mean the IEEE? Does this cover the MIB document?

Tissa: The MIB document needs more work.

Donald: I believe a formal response from an 802.1 meeting will not
occur until their next meeting which is the week after the November
IETF meeting.

Tissa: So it will probably be the IETF meeting after the November
meeting. These are the next steps. Thank you.

20 min.  Directory Assist Mechanisms, Linda Dunbar
==================================================
         draft-dunbar-trill-scheme-for-directory-assist-05
         draft-eastlake-trill-ia-appsubtlv-00
	 draft-dunbar-trill-directory-assisted-encap-04

Donald: We only have 13 minutes left in this in this session so, if it
is OK with people, I'll just continue to sit here and quickly go
through the Directory Assistance mechanisms presentation [No
Objections] [see slides].

Donald: There are two drafts associated with this. One [ia-appsubtlv]
is just a data representation. The other covers the mechanisms. The
idea is to reduce multi-destination packets by reducing or eliminating
unknown MAC destination flooding and locally responding to at least
some ARP, NH, and RARP packets, possibly converting them to unicast
requests to a directory. This is done with directory information that
can, for example, map from an IP address to a MAC address or from a MAC
address to its RBridge of attachment.  All of this is Data Label
scoped. Data center orchestration systems are believed to be an
appropriate source of directory information. There are two kinds of
directories: Push and Pull.  ... Supports redundant
directories. ... ESADI used for Push Directories. ... An RBridge
Channel protocol used for Pull Directories. ... Pull Directory can be
hosted on an end station.  ... Edge RBridges using directory services
can have a wide variety of policies. ...

Erik: Push directories are per VLAN. Is that true to Pull also?

Donald: Yes, this is all scoped by Data Label, VLAN or Fine Grained
Label.  Pull Directories advertise themselves in the core link state
database but do that per Data Label. So a Pull Directory can say "Here
I am, you can pull address information from me for VLAN 17." ...

Donald: The WG has passed the draft-ietf-trill-directory-framework
framework draft and decided on this direction. The authors of the
directory assistance mechanisms draft would like to do one more pass
to polish it and think that it then might be adopted by the WG.

Erik: How many people have read this draft? [Only a couple other than
the authors.] Please read the draft and post to the WG list. It's fine
if you think it OK. Just post a message saying that.

Donald: So, we theoretically have 5 minutes left in this session and
have two presentations, so I don't know how that is going to go.

Linda Dunbar: [presentation on pre-encapsulation, see slides] There is
also a draft on "smart end-nodes" but that is more related to address
learning by end nodes and is more complicated. This draft was
originally part of the same draft with the directory framework and
scheme but it was recommended to split it up. ... Can reduce MAC
learning tables at edge. ... Better load spreading because
pre-encapsulated packets do not have to be sent to the appointed
forwarder for their Data Label. ... No change to egress RBridge. Only
configuration change to ingress RBridge. End station now needs to do
TRILL encapsulation based on directory information. ... Next step: WG
adoption.

Erik: How many people have read this draft? [4 or 5] Please send
comments to the mailing list so we can see if the WG is ready to adopt
this draft.

X: When is the deadline?

Erik: Tomorrow. [Laughter] Well, people work based on deadlines right?
... How about in one week? That would be good.

Donald: Well, we have only one more presentation so I think we should
go ahead on that.

10 min.  Active-Active Edge Problem Statement, Yizhou Li
========================================================
         draft-yizhou-trill-active-active-connection-prob-00

Yizhou Li (Huawei): [presentation, see slides] I just want to go
through this quickly so people can go to the social. ... MC-LAG so
Hello packet cannot go between different RBridges. ... Problems: Frame
duplication ... Loop back ... (not continuous loop) ... Address
flip-flop ... RFP Check (solution dependent) ...

Tissa: I think you should stay with the general problems rather than
talking about the problems of specific solutions.

Yizhou: Last problem is information inconsistency between the edge
group of RBridges. MC-LAG not standardized. ... Information to
synchronize is solution dependent but some synchronization seems
needed for any solution. ... Seeking comments.

Erik: Please read and comment on this draft. Can we use this to create
a table of problems and solutions?

[Session ran over, recording ends]

Donald & Erik: Sorry that this session ran over. See you on the
mailing list and in Vancouver.