Minutes for TRILL at IETF-91
minutes-91-trill-1

TRILL Working Group Minutes
Chairs: Sue Hares (Hickory Hill Consulting), Jon Hudson (Brocade)
Secretary: Donald Eastlake (Huawei)

Date:   Wednesday, 12 November 2014
Facility: Hilton Hawaiian Village Hotel, Honolulu, Hawaii
Room:   Kahili Room
Time:   15:20-16:50

Minutes by Donald Eastlake (Secretary, Huawei), Hao Weiguo (Huawei),
and Andrew Qu (MediaTek).


ACTION ITEMS:
-------------

1. draf-eastlake-trill-rfc7180bis-01.txt was announced as adopted by
the WG [done:
http://www.ietf.org/mail-archive/web/trill/current/maillist.html]

2. Proposed new milestones will be posted to the TRILL WG mailing
list. [done:
http://www.ietf.org/mail-archive/web/trill/current/msg06519.html]

3. WG Last Call will be issued for draft-ietf-trill-oam-mib-01.txt
[done:
http://www.ietf.org/mail-archive/web/trill/current/msg06508.html]

4. Poll for WG adoption will be issued for
draft-hao-trill-centralized-replication-02 [done:
http://www.ietf.org/mail-archive/web/trill/current/msg06521.html]

5. WG Last Call will be issued for
draft-ietf-trill-pseudonode-nickname-02.txt [done:
http://www.ietf.org/mail-archive/web/trill/current/msg06509.html]

6. WG Last Call will be issued for draft-ietf-trill-aa-multi-attach-04
[done:
http://www.ietf.org/mail-archive/web/trill/current/msg06511.html]

7. WG Last Call will be issued for draft-ietf-trill-cmt-03 [done:
http://www.ietf.org/mail-archive/web/trill/current/msg06520.html]

8. Poll for WG adoption will be issued for
draft-dunbar-trill-directory-assisted-encap-08.txt [done:
http://www.ietf.org/mail-archive/web/trill/current/msg06522.html]

9. Poll for WG adoption will be issued for
draft-perlman-trill-smart-endnodes-04.txt [done:
http://www.ietf.org/mail-archive/web/trill/current/msg06515.html]


DETAILED MINUTES:
-----------------

[Times shown for agenda items are the time originally scheduled, not
the time actually taken.]

[Note Well slide shown]

Sue Hares (Co-Chair, Hickory Hill Consulting): People should move up
front in the room so they can hear better.

Jon Hudson (Co-Chair, Brocade): We don't bite.

Sue: At least not on Wednesday.

[Meeting called to order at 15:25]


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

Sue: Jon and I are your new Chairs. But Donald is here to help as
Secretary.  We are going to give you some administrivia and them
document status. Going over the agenda ...  By the way, can anyone
take a second set of notes especially when Donald is talking? Thanks
Weiguo and Andrew. ... continuing going over the agenda.


15 min.  Document Status,
-------  Review of Milestones, Chairs

Sue: Document status - see slides that are on line - ...

Sue: The rfc7180bis draft is in call for adoption and, as far as I can
see, it has been adopted. If you have any concerns, let us know. [No
one spoke up.] ...

Jon: Our main priorities are OAM, Active-Active, Directory Assist /
ARP&ND optimization. We will do other nifty things but we want to bang
these out pretty quickly. I cannot emphasize the importance of OAM
enough. It drastically affects customer views of TRILL.

Jon: OAM should be focused on as market really impacted by OAM.
Active-active is a must and demanded by market. Having multiple
interfaces on a host is a given. Finding a good way to do this is very
important and may apply outside of TRILL.  Directory-assistance is
important and maybe should have been done earlier. Proprietary
implementations of TRILL all have such a feature. It is important for
management of the network.

Sue: Milestones. Many have been completed but we do have some overdue
due to prioritization of OAM and active-active. Future milestones,
Security ones are particularly important.

Jon: There is a lot of value to security. TRILL tries to be minimal
configuration. If we can find a way to do Security with little to no
configuration, that will be great.

Sue: If we run out of milestones and are waiting for implementations
to catch up, it is possible to put a WG into a hiatus state. Here are
the proposed new milestones. I think they correspond to what we have
been saying. [See slide.] We will check on the mailing list but we
think these are good.

Doug Otis (TrendMicro): I have tried to promote TRILL and I get some
pushback in respect to wireless due to chatty nature of TRILL control
plane. Also chatter of multicast DNS. Flat L2 space is large and that
causes concern. That seems to be the biggest problem in getting it
deployed. Also better security needed.

Sue: If you have a few minutes after the meeting perhaps Donald and I
can talk with you.

Doug: We have a large campus and have configured a lot of VLANs, which
are very easy to configure with RBridges.  This helps a lot but it is
hard to convince people of that.


 5 min.  TRILL OAM Status Update,
-------     Tissa Senevirathne, Deepak Kumar
	 draft-ietf-trill-oam-mib-01
         draft-ietf-trill-yang-oam-00

Deepak Kumar (Cisco): [See "TRILL OAM" Slides] I am speaking on behalf
of Tissa. OAM Requirements and Framework have been issued as RFCs. OAM
FM [Fault Management] and PM [Performance Management] are in the RFC
Editor's queue. OAM MIB and OAM YANG are WG drafts. On the MIB draft,
we would like WG comments - perhaps WG Last Call. A Generic YANG model
has been submitted to the LIME WG. We expect to coordinate with LIME.

Sue: You might also send it to the Routing YANG group as a courtesy.

Deepak: The Routing group has already reviewed the Generic YANG
draft. TRILL OAM YANG should also be reviewed there. TRILL OAM YANG
for PM is an open item.

Sue: Are you planning to write a document [for YANG TRILL PM]?

Deepak: I've started and would welcome co-authors.

Jon: Thanks, we appreciate the effort.

Sue: Are there any comments on the MIB? Is there any objection to a WG
Last Call on the OAM MIB? OK, Last Call will be posted. Are there any
comments on the YANG document?


10 min.  TRILL Clarifications, Corrections, and Updates
-------     Donald Eastlake
         draft-eastlake-trill-rfc7180bis-01

Donald Eastlake (Huawei): [see Slides] Existing RFC 7180 is on
Clarifications, Corrections, and Updates to the base TRILL documents.
Earlier documents and RFC 7180 itself were delayed a bit in
publication due to normative dependencies. Further update is needed
now.  I'll go over what's being added to, deleted from, or left in RFC
7180 by the rfc7180bis draft.  ... Add E-L1FS support.  ...  Add
alternative RPF Check. ... Add Nickname Flags APPsub-TLV.  ...
Deprecates extending the TRILL Header beyond one word of added flags.
...  Add optional color and extended hop count bits.  ... Add some
informative appendicis. ... Things taken out are previously included
changes to RFC 6327 and RFC 6439. The changes to RFC 6327 have been
included in RFC 7177. The changes in RFC 6439 should be included in an
rfc6439bis.  Everything else is retained.  There could be further
additions but this draft should move forward rapidly because other
drafts depend on it, particularly on E-L1FS support.

[There were no comments or questions from the Audience.]


10 min.  Centralized Replication for BUM Traffic in Active-Active TRILL Edge
-------     Weiguo Hao
         draft-hao-trill-centralized-replication-02

Hao Weiguo (Huawei): [see Slides] ... Motivation is when we use data
plane learning.  Pseudo-nickname is used to avoid flip-flop at remote
RBridge.  ...  Overview of RPF check problem. Avoided by centralized
replication ... Together provide a comprehensive active-active
solution.  ...  Unicast encapsulate multi-destination to tree root that
then distributes it. ... RPF check done as if the ingress was the
root.  ...  Local forwarding behavior. ... BUM traffic load balancing
among multiple centralized nodes.  ... TRILL extension Nick Flag bit
to indicate nickname used for centralized replication. ... I think
this is a correct, applicable solution for TRILL active-active. Seek
some comments and feedback and call for WG adoption.

Jon: How many people have read this draft? Are there any objections?
Is everyone happy with how it is progressing? I would love to hear any
concerns, even minor.


 5 min.  TRILL Active-Active Status/Summary
-------     Hongjun Zhai, Tissa Senevirathne, Yizhou Li,
            Weiguo Hao, Mingui Zhang
         draft-ietf-trill-aa-multi-attach-04
         draft-ietf-trill-cmt-03
	 draft-ietf-trill-pseudonode-nickname-02

Donald Eastlake (Huawei): [see Slides] This is a brief status summary
for Active-Active TRILL Edge. CE are today connected by proprietary
Multi-Chassis LAG which can handle one box at one end and multiple
boxes at the other end. For example 1 to 4.  But some other protocol
could be running on the link to the CE devices.  The IETF just got a
liaison from IEEE 802.1 about a revision to Link Aggregation [LAG],
which is 802.1AX, that is quite far along in the process. This
802.1AX-REV will allow multiple devices at both ends but will, as I
understand it, be limited to a maximum of 3 on each end. ... As a
practical matter the edge group TRILL switches will always be from the
same manufacturer but you might have mixed remote RBridges so those
remote RBridges should not have to be modified to support
active-active.  Next slide. Here is a list of previous presentations
to the WG on active-active. ... Pseudonode-nickname assumes a nickname
for a fake RBridge that the CE appears to be attached to. In
aa-multi-attach the CE is seen as connected to all the edge RBridges.
CMT is a solution to the RPF Check problem but requires that the edge
group be no larger than the number of trees you have. We just saw
centralized replication which can fix the RPF Check problem without
that restriction. CMT also has other uses. ... Pseudonode-nickname
works best for data plane learning while aa-multi-attach works best
with control plane learning. Looking at the draft dependencies, both
depend on rfc7180bis which is one reason it should be high priority.
You could have pseudonode-nickname and aa-multi-attach both deployed
in the same TRILL campus at the same time. A particular edge group
would have to use one or the other but different edge groups could use
different strategies.

Fangwei Hu (ZTE): The smart end node draft could be added. It depends
on aa-multi-attach.

Donald: Yes. This does not claim to be a complete chart of TRILL draft
dependencies, just those for active-active.

Hao Weiguo: You chart is very clear. For data plane learning and
control plane learning, you can have both in the same network at the
same time. For example, some VLANs can use centralized replication
solution and some VLANs can use as-multi-attach solution.

Donald: I would have said some edge groups use one and some edge
groups use the other. I haven't thought about trying to use VLANs to
determine which.

Weiguo: This is just one partition method. But they can co-exist in a
single physical network.

Donald: Yes. Next Slide. So, since this is our highest major priority,
I suggest that we WG Last Call CMT, pseudonode-nickname, and
aa-multi-attach.

Sue: Donald, are you OK with WG Last Call with all at the same time?

Donald: Yes, although if we do them all we might want to run it for
longer than usual since it is more to review. I will also commit to
trying to get the rfc7180bis draft ready for WG Last Call within a few
weeks. 

Sue: I'd like to ask the room: we have gone through these drafts
several times in IETF, since e are pushing these a bit, does anyone
feel that we need an interim meeting to go over them again?

Jon: Please, if there are any reservations at all, speak up.

Sue: But we can use the interim process if you want a tutorial or have
questions. 

Donald: I would point out that people can post questions during WG
Last Call also.

Andrew Qu (MediaTek): Pseudo-nickname approach has been deployed by
vendors already and is quite mature. I have no problems with last
calling it and CMT.


10 min.  TRILL over IP, Margaret Wasserman, Dacheng Zhang, Donald Eastlake
-------  draft-ietf-trill-over-ip-01

Margaret Wasserman (Painless Security): [see Slides] TRILL over IP
specifies a natural IP/UDP encapsulation for TRILL and treats IP as a
link. So you can connect sites over IP into one campus. Current
security encapsulation uses DTLS so you have TRILL over UDP over DTLS
over IP in the secure case. That's what's in the current draft.  ...
Security does not interfere with IS-IS authentication.  ...  Work
remaining: Congestion... Middle Box... QoS Considerations... Port
configuration specification... Bigger issue is that current draft uses
obvious choices from an application development viewpoint without
really taking into consideration the fast path implications. So we
have some questions we should consider as a WG.

Weiguo:  Is a TRILL over IP port a physical port or a logical port?

Margaret: I guess it is a physical port but there is logical
configuration so I'm not sure how to answer this... Donald?

Donald: Well, there is a physical port but that port could have more
than one IP address so it could look like multiple TRILL over IP
ports. So the root is a physical port. But it could have both an IPv4
and IPv6 address and there would be configuration for each of those
for example.

Margaret: If two TRILL switches are connected by TRILL over IP you
have a physical port on each of them. Theoretically other ports could
also be on the IP network. But above the physical port you could have
multiple interfaces to the TCP/IP stack because there is not always a
1 to 1 correspondence.

Andrew: I'm not sure what Weiguo's concern is but since this TRILL
over IP is a logical connection, to me, the port is not so important.
Does not matter what the carrier is as long as you have a
point-to-point IP connection.

Margaret: You can have two physical ports that are aggregated into
one but then have three interfaces to the higher protocol stack. This
is where it isn't 1 to 1.

Sue: I think we have clarified this enough for now. Thanks Margaret.

Margaret: OK. We have a question on the security protocol. We have
specified DTLS but there is a lot more hardware support, ether
off-load support or fast path support, for IPsec in switching chip
sets.  In either case we can do default keying based on IS-IS keying
so the main concern is the data frame format between the outer IP
header and the inner UDP header.  ...  And it seems undesirable to
have to support two security protocols for TRILL.  Since IPsec has
much more widely available hardware fast path support the draft
authors are suggesting we switch to IPsec. Discussion?

Andrew: Why don't we leave this orthogonal? If you consider Data
Center interconnected, normally the IP data itself has whatever
security.  So as long as we take care of TRILL over IP and let the
generic security that does IP security between the Data Centers or
branch office take care of it since we have already formatted it as an
IP packet. Let IP security devices do security on its own unless you
want to put it into this protocol. IP has a lot security tools out
there already, just take advantage of it...

Margaret: We are talking about encapsulating TRILL packets and TRILL,
like any IETF protocol, needs to be secure. We are looking for a way
to protect the TRILL packet. Every TRILL [over IP] implementation is
going to have to implement this. If we just say "do what you want" we
won't have interoperability. One vendor could do IPsec, one could do
DTLS, one could do something proprietary... We need to list one
mandatory to implement security protocol for TRILL over IP.

Jon: Because of the way a lot of these products are produced, while
IPsec is very common, it is not common in Data Center switches. So
IPsec being more available in hardware might not be true in this
case. 

Margaret: There are chip sets that will do IPsec. I'm not sure there
are any that do DTLS. So I could do IPsec in available hardware but I
don't think I could do DTLS.

Andrew: At this moment, TRILL is usually deployed in Data Centers,
proprietary, or in the cloud. And this is normally implemented in
ASICs. As far as I know, no ASIC out there can do IPsec. There may be
NPU that can do it.

Margaret: So you are saying you will come out of the fast path for
either IPsec or DTLS.

Andrew: So you are saying the operator has to do this for TRILL.

Margaret: A mandatory to implement does not mean that everyone has to
turn it on. If you have a campus with some other kind of security, you
don't have to turn this on. If you have a remote office, I can't
imagine that you wouldn't want to run some kind of security. You might
run over a lower level VPN or something but somewhere you are going to
want to encrypt these packets so that your traffic isn't visible on
the network and your control traffic can't be corrupted.

Donald: Yeah, you can always use some sort of tunnel or something. I
don't think it matters much inside a Data Center because the links
there between adjacent TRILL switches are not IP, they are usually
Ethernet.  This is only if are encapsulating things over IP, probably
for a somewhat larger distance. Not necessarily over the global
Internet but probably getting out of the room.  If you are doing TRILL
over IP you would want to have security available and if one protocol
has better hardware support, it seems like a factor in favor of that
protocol.

Jon: But you need to consider the case of a tenant inside a Data
Center that would need to traverse part of that Data Center before
getting to the outside. So they may have to do this.

Margaret: Well, we have received some feedback that IPsec would be
better.  I'm not hearing any feedback that DTLS would be better, only
that IPsec isn't better. Does anyone want to argue that DTLS is better
or are you just saying it doesn't matter? If some people think IPsec
is better and everyone else doesn't care, then we switch to IPsec,
right?

Sue: OK. Do we have any people with deployments with comments?

Margaret: If we have people who have already implemented TRILL over
IP with DTLS, that would be an argument not to change it.

Sue: Any further comments?

Andrew: For Data Center interconnect -- VPLS -- for Layer 2 normally
secured with EVPN or IP over GRE or ... also let the Data Center
operator worry about it. If we require support of IPsec I'm afraid the
operator will need an extra device to do this job. If we just say...
ask security guys.

Margaret: There is a distinction between mandatory to implement and
mandatory to turn on. You don't even have to make the default to be
that it is turned on. So maybe in a Data Center no one would ever run
it over IP but when we make a protocol run over IP we instantly have
the possibility that someone will run it over an open IP network. So,
we hold in the IETF that any protocol running over IP must have a
mandatory to implement security protocol so that people running it
over the Internet can turn it [security] on. That doesn't mean people
running it in a Data Center need to turn it on; they can leave it
off. But when you get to the remote office scenario the name "remote
office" pretty much implies they are not in your Data Center so you
need to have a security protocol you can run if the path to the remote
office is not secure. That is why the IETF has the policy that there
must be a mandatory to implement security mechanism. This is really
only for that sort of remote office or where you have two TRILL
campuses running over an IP backbone with other people and you want to
secure the TRILL traffic.

Donald: I think one thing Andrew was talking about, he can correct me
if I am wrong, is various secure layer 2 ways of connecting parts of a
TRILL campus. That's fine but that isn't TRILL over IP, that's TRILL
over layer 2. Your layer 2 might be tunneled over IP but from what he
was talking about, the layer 2 is already secured. That's fine, but
this is for TRILL directly over IP.

Margaret: OK, but let's say it's TRILL directly over IP but the IP is
over a secured line leased from some vendor who secures it. Then I
don't have to turn on this feature.

Donald: Right.

??? (???): If we are connecting separate domains of TRILL, this seems
analogous to Fiber Channel over a tunnel. You might have native Fiber
Channel encryption ... and you might have tunnel encryption. To me,
those are orthogonal levels of encryption. The other thing, from a
network design point of view, if you are running your TRILL over IP,
you were saying a campus, you have your students using the same
network, so something is very wrong with your network design.

[Note: it is possible that the speaker above was unaware that the term
"TRILL campus" is just a term for a TRILL network, like "bridged LAN"
is a term for a bridged network, and has nothing to do with students
or academia.]

Margaret: I don't think you would have students using the same
network.  But in the remote office scenario, a small campus, you want
to connect to your main TRILL campus, you might want to run over a
VPN, and despite P standing for Private, this might go over an IP
network unencrypted through intermediate routers and there might be
man-in-the-middle attacks, right?

???: Yes but why don't you just run two tunnels, one for TRILL over
IP, and one for everything else. Much simpler to operate.

Margaret: So you would run a tunnel from the remote office?

???: Two tunnels, one for TRILL over IP and one for everything else.

Margaret: I don't know what everything else would be in that case. In
any case, we can't specify in the TRILL document how "everything else"
is handled. But you are saying that TRILL over IP should require a
dedicated tunnel.

???: Yes.

Margaret: And that the tunnel should be encrypted and that is what we
should specify?

???: That is the network design level, how you design and run your
network, and personally I wouldn't see much protocol work. You run two
tunnels, one for TRILL over IP and one for everything else.

Margaret: And somehow the TRILL tunnel ends up encrypted or else it
isn't a security mechanism at all?

???: In my view, encryption of the TRILL tunnel is orthogonal. You
encrypt the tunnel transport.  ...  To give an example with Fiber
Channel, you can have native Fiber Channel encryption. ... If you are
really paranoid you can run that over an encrypted IP tunnel. Whether
than makes practical sense, I don't know.

Margaret: The problem is that unless we can guarantee through
something in our protocol that it will never be run over an insecure
network, we have to specify a mandatory to implement security design
in our protocol. This is an IETF policy. Whether everyone will
implement our mandatory to implement protocol, well, we don't have
police and people will do what they think is right for their
product. If you build a Data Center only product that doesn't include
security, the police are not going to do anything to you. But we
believe that anything specified to run over IP will eventually be run
on the open Internet so it must be possible to secure it. Security can
be turned off by default but it has to have the capability to be
secured so it can run over the open Internet.

Andrew: Sure but this is an IP packet, so the exit of the Data Center
will already have what security is needed. We don't have to specify it
here, the equipment is already there as long as it is an IP packet.
They will encrypt it according to your instructions.

Margaret: So you are saying that this whole thing [the TRILL over UDP
over IP] will be encrypted because there is an IPsec header here
[before the initially added IP header]? We could specify that in our
document. So that would mean, in the secured case, we have TRILL over
UDP over IP over IPSEC over IP.

Andrew: Yes. I make this IP packet already. All the IP security
appliances encrypt the whole thing. The tools exist, we don't want to
invent a new feature. If we come up with something new, I don't know
if vendors will want to implement it. There is a lot of overhead in
ASIC design. If we don't see any major need to do this, it will
confuse all the ASIC designers.

Sue: Thanks Andrew, Jon and I have heard you. I think we have gone
through all the points.  Does anyone have any new points? [no
response]

Margaret: We have one more issue. That's encapsulation. Current draft
only supports natural UDP encapsulation. But we have been told there
is more hardware support and perhaps more flexibility with other
encapsulations. The one that comes up most frequently is VxLAN. There
was a consensus determination that the TRILL WG preferred UDP/IP to a
new custom encapsulation such as a new IP protocol number. But we
would just be using existing standard encapsulations, not defining a
new one.  For example, we might want a TRILL in VxLAN. Do people think
that is needed to get high performance? Any comments or questions?

Jon: I know of one implementation that does exactly this but I don't
know how much performance benefit there is.

Margaret: Well, they will get better performance if they have fast
path support for TRILL in VxLAN but not for TRILL in UDP, right? So
the question to ASIC designers is do you support TRILL over VxLAN or
TRILL UDP?

Andrew: The chip we are designing can already do TRILL over VxLAN and
TRILL over GRE. Of course, it takes two passes through the ASIC to do
this because we think this will be an uncommon corner case. We did not
design it to do it in one pass.

Margaret: So, that sounds like we should do the VxLAN encapsulation.
Does anyone thing we should not do the VxLAN encapsulation?

Jon: My only hesitation personally would be about saying it must be
VxLAN.

Margaret: I think the idea was to keep the UDP encapsulation and add
VxLAN. So you could use TRIILL over IP with either direct UDP or
VxLAN. 

Donald: I think the idea was that it might be hard to do some
encapsulations so there would be a way to reach agreement about what
you both support.

Margaret: Our suggestion is that the default is to use TRILL over UDP
for Hellos. They are not frequent, so fast path support is not so
important.  Then capabilities in the Hello would indicate what
encapsulations are supported. ... There would be a very simple
negotiation.  If you share an encapsulation, you use that and if you
don't share one, then there is no data connectivity. Anyone have any
thoughts?

Weiguo: I think to be accurate, it is TRILL over Ethernet over VxLAN.

Margaret: Right. Any other feedback or questions?

Andrew: Just to follow up on Weiguo, TRILL over IP or TRILL over
Ethernet over IP will put more burden on the IP header to indicate
whether a Ethernet header is encaped. To ASICs, I really have to know
if there is a Ethernet header there.

Donald: How about if I assure you it will be well defined?

Andrew: OK because the hardware really needs to know.

 5 min.  Directory Assisted Edge Status
            Donald Eastlake, Linda Dunbar
         draft-ietf-trill-directory-assist-mechanisms-00
         draft-ietf-trill-ia-appsubtlv-01
         draft-ietf-trill-chanel-tunnel-01
         draft-dunbar-trill-directory-assisted-encap-08

Donald: [see Slides] This is a status update on Directory Assistance.
With it you can get directory information from Push or Pull
directories.  Directory information is really a set of addresses that
all correspond to one interface. For example, a MAC address and an
IPv4 address, ... plus the edge RBridge they are attached to. ...
With that information, you can answer ARPs and NDs, so you can do ARP
and ND optimization. With complete directory information that you are
really sure is complete, you don't have to flood unknown addresses
because if you get a MAC address that is not in the directory, you
know it is bogus and you can just toss it. With complete directory
information, you can even reject frames with a forged source MAC or IP
address because if you are an edge RBridge and get a frame from an end
station but the directory says that MAC address or IP is attached to a
different RBridge, you know it is bogus. You can even tell if it is
attached to the right port of an RBridge if the directory is carrying
port of attachment information. Push directories use ESADI. Pull
directories send queries and get responses. ... [List of
presentations.]  ...  [list of drafts] directory-assist-mechanisms is
actually -01. ... The channel-tunnel draft actually covers three
different orthogonal mechanisms.  You can do any one or two or all
three. One is security, which is why it is referenced by
directory-assist-mechanism, to secure Pull directory queries and
responses. There is also a payload type that is useful. But I think
the third "scope" mechanism makes it a bit too much. I'll send a
message to the WG list suggesting it be split out. So there would just
be two mechanisms in the draft.  ...
dunbar-trill-directory-assisted-encap describes an asymmetric
pre-encapsulation scheme using existing TRILL features and says why
that would be useful, saving space in the MAC tables of edge
RBridges...

Sue: Donald, that savings permits smaller edge nodes, right?

Donald: Yes, it allows edge RBridges to be cheaper/smaller. Here is
the draft dependency. ... This is lower priority than active-active
but the directory-assisted-encap has been around for a while so I'm
suggesting we could poll for WG adoption. ... I don't think these are
ready for WG Last Call yet.

Sue: Any concerns?  [no response]


 5 min.  Smart End Nodes, Hu Fangwei
 ------  draft-perlman-trill-smart-endnodes-04

Fangwei Hu (ZTE): [see Slides] TRILL Smart Endnode. Motivation is to
save endnode learning table, quickly refresh the node table, and
supports fine grained label aware end station. ... Changes from last
time draft was polled for WG adoption. ... I'd like to call for WG
adoption. 

Sue: OK. Any comments? [no response] We will re-echo this to the list.
Please read the drafts because we will be progressing these call for
adoption pretty quickly. Thanks for your presentation Fangwei.

 5 min.  Wrap-Up, Chairs

Sue: Anything else before we close the WG session? I'd like to ask the
wireless person to talk to Donald after the meeting ...

Sue: Thanks you all so much.