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

Hilton Buenos Aires, Buenos Aires, Argentina
	Wednesday, April 6, 2016. 
	10:00–12:30 Quebracho Room

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

Notes by Donald Eastlake.
Times given are those originally scheduled for the items, not
necessarily the time actually taken.


  6 min. Administrativia (scribes), Agenda Bashing, Chairs
  ================================================
[see slides]

Sue Hares (Co-Chair, Hickory Hill Consulting): Come on up to the
front. We would like the meeting to be participatory.

Sue: OK. Good morning. This is the TRILL WG, Jon and I are the Chairs.
Donald is the Secretary and Grand Poobah. Actually he does lots of
things and Jon and I appreciate his assistance.

Sue: This is the Note Well.  Please read it.  For new people, the Note
Well is what you have to read if you are making any contribution to
the IETF.  If you contribute anything in writing or verbally, it is
subject to the rules of the IETF.  These rules help us share our ideas
in a collaborative way. If you have questions, ask the Chairs.

Sue: Our agenda is show. We are starting a little behind time.  [Sue
reviewed the agenda slides.]  Any questions on the agenda? [There were
none.]


  6 min.  Status, Review of Milestones, Chairs
  ====================================

Sue: We have made good progress on our documents since the last
meeting.  [See slides] ...  If you have questions, let us know. On the
directory drafts we are getting good feedback from the Routing
Directorate.  Please send any comments you have even if they are on a
draft that is already through WG Last Call. Comments are always
appreciated.

Sue: We recently completed the Active-Active milestones but we do have
a few milestones overdue. ...

Donald Eastlake (Huawei, Secretary): Just to note that we do not have
(and do not need to have) milestones for every document going through.
Probably the milestones should be updated and perhaps a few milestones
added.

Sue: If you have a document that has been adopted by the WG and would
like milestones for it to be added, check with the Chairs.

Jon Hudson (Brocade, Co-Chair): Anyone interested in scribing for this
meeting?  There is a T-shirt in it for you. ...

Sue: There is an Etherpad. We would appreciate it if you speak at the
mike if you would at least put your name in the Etherpad. That will make
it easier for our scribe.


 12 min.  TRILL Address Flush Message, Hao Weiguo,
 ====================================
 draft-hao-trill-address-flush-01 

Yizhou Li (Huawei): [see slides] I'm going to present an update on the
address flush message. Weiguo is the primary author on this draft but
he is usable to make this meeting. Background: there are five ways to
learn addresses in TRILL.  ...  Data plane learning is the most
common.  ...  Forgetting is also important. Data plane forgetting
currently just uses time-out.  ...  In this document we address more
efficient data plane learned address forgetting. There was discussion
at the last meeting with follow-up on the mailing list comparing using
an RBridge Channel message with ESADI. Consensus appears to be to use
an RBridge Channel message.  ...  Variations on the message.  ...
Next steps: Please look at draft, we believe there should be an
adoption call.

Sue: Any concerns with going to a WG adoption call? [none] OK, the
Chairs will go to a WG Adoption call.


 20 min.  TRILL ECN Support, draft-eastlake-trill-ecn-support-00
 ==========================

Bob Briscoe: [see slides] A bit of context: Explicit Congestion
Notification was added to IP as a Proposed Standard in 2001. Any
change to IP takes years to sort out. ... ECN marks a packet as
opposed to dropping it so you get an immediate signal rather than
guessing. So far it has been deployed for IP more in private networks
such as data centers. It is very widely used in Google's networks and
Microsoft’s mostly due to a thing called Data Center TCP.  ...  This
has become more relevant recently. Apple and cellular networks are
trying to deploy it. At places where TRILL is deployed like IXPs
[Internet Exchange Points] it important to get support for this.  ...
Because this is being added to the TRILL standard later, you have to
be sure that the egress TRILL switch understands it.  The way this was
handled at Layer 3-4 was that the ends negotiate and packet is marked
at the beginning as having an ECN capable transport if the end
supports it.  Transit nodes where there is congestion then either mark
the packet as having experienced congestion, if the packet is already
marked as ECN capable, otherwise the transit node drops the packet. So
that's how ECN works, using 2 bits in the IP header.

Bob: TRILL has a similar incremental deployment problem but the
question is whether the egress RBridge will understand ECN well enough
to propagate it into the enclosed IP header. There are three
possibilities: (1) Have TRILL switches mark directly in the enclosed
IP header. (2) Use a router advertisement by the egress RBridge so the
ingress only marks the TRILL header if the egress supports ECN. (3)
Use a critical ingress to egress flag - which turns out to be a really
smart way to do it.  For the rest of this talk we will ignore 1 as
impractical although I'd like to hear any alternative opinions.

Donald: You could argue that all of TRILL is Layer 3 switches but what
possibility 1 requires is penetrating the TRILL layer to change the
encapsulated IP header. This is not deep packet inspection but deep
packet manipulation. Seems like a bad idea.

Bob: Right, and if the inner data is compressed or encrypted, it would
be impossible. So set that aside. The second method is what is in the
current draft. After I talk about that, I'll talk about the third way
which we thought of a few hours before the draft deadline but didn't
get into the draft. ... Method two ...  copy inner marking to TRILL
header on ingress ... merge from TRILL header to IP header on egress
...

Bob: Method 3, uses the same two non-critical hop-by-hop bits in the
TRILL Header flags word but says that the 11 congestion encountered
value is not used. We put the congestion marking in a single critical
ingress-to-egress bit.

Sue: That's cool.

Bob: Yes it is, isn't it... It's really cool because TRILL was really
well designed for forward compatibility.  ...  So there need be no
previous negotiation. You just always do ECN marking, if you are a
transit RBridge that supports ECN, and the drop/merge decision is
deferred to the egress. If the egress does not understand ECN, it will
drop, which is the desired behavior. So there are no failure modes
where the routing system thinks one thing but the actual path is
different or anything like that. You just always do marking.  Copying
the IP header ECN bits to the TRILL header is not logically necessary
and the bits are not looked at by transit RBridges but they are useful
for alternative uses of ECN. So transit RBridge just write without
having to read ECN bits. A critical ingress-to-egress bit set only
causes drop at the egress. ...  If the egress does support ECN, the
bits are merged as show [see slide].

Bob: Before we go for comments, one more thing. I'm working with a guy
...  and we did a demonstration of ultra low latency over the public
Internet with Data Center TCP and that's using ECN.  There is a sort
of even more difficult problem with that. The ECN mark is not
equivalent to drop, you have a lot more marks that you would drops, to
make it more fine grained. With the way TRILL was designed, using an
ingress to egress flag, we can actually get the egress RBridge to drop
proportional to the square of the mark probability even if it is
ignorant of ECN. [see code on supplemental slide] We ought to have a
BCP on this is how you should design protocols. Any questions?

Donald: ...  Does anyone have any objection to switching the draft to
scheme 3 that seems to be clearly superior? [no objections] The only
disadvantage is that is uses up one more bit in the Flags Word but
there is currently not shortage of bits.

Sue: I think it is really cool.

Donald: So people should expect to see a revision of the draft and
then a call for WG Adoption. Of course, we could adopt it and then
revise the draft but it seems better to revise it as a personal draft
and then adopt it.

Sue: OK. The next presentation is also an interesting addition.


 12 min.  Smart End Nodes, Fangwei Hu,
 ========================
 draft-ietf-trill-smart-endnodes-03

Fangwei Hu (ZTE): [see slides] This is an update of smart endnodes.
The draft has been updated from -02 to -03. Changed: some editorial
fixes, ... clarification ..., added some procedures, updated IANA
Considerations, updated references. ...

Sue: Any questions about smart end nodes before we go to WG Last Call?

Donald: There are actually two drafts that relate to specialized end
nodes.  The smart endnode draft and also the directory assisted
encapsulation draft. Both assume that directory information can get to
the end node. We have these directory drafts that are in publication
requested state that provide push and pull directories. They include a
way to host a pull directory on an end node. But there is currently no
way for and end station to actually originate a pull request (only
RBridges can) or to have directory information pushed to it. ...  I
think we need to fix that.  As soon as that is fixed, then I think
smart endnode could to go WG last call. I believe the idea is to have
a separate little draft that just talks about extensions to directory
to provide a reliable and standardized way for directory information
to get to end nodes.

Fangwei: Thank you.

Sue: There is a multi-homed scenario in Section 6. Should there be
other scenarios in the draft? Such as with and without ESADI?

Donald/Fangwei: [inaudible]

Sue: OK, and then I think this should go for last call. It is a really
nice addition to TRILL.


  6 min.  Group Keying, Margaret Cullen, Dachang Zhang, Donald
  ====================
 Eastlake, Mingui Zhang, draft-ietf-trill-over-ip-05,
 draft-ietf-trill-channel-tunnel-08 

Margaret Cullen (Painless Security): [see slides] This is about two
drafts.  The TRILL Over IP draft treats IP as a link. Then there is
the Channel Tunnel draft about securing RBridge Channel messages.
These are not related drafts except that they have a related problem.
Both of them need a group keying mechanism so that multi-destination
packets do not have to be sent with serial unicast.  ...  We don't
have a group keying mechanism yet. In TRILL Over IP this applies if
native multicast is supported on the IP Link and in Channel Tunnel
this applies to multi-destination RBridge Channel messages on the
virtual link.  ...  The idea is to have one mechanism that can be used
in both of these cases and the lack of group keying is currently
delaying both of these drafts.  ...  Group keying has already been
removed from the Channel Tunnel draft that now says it will be
covered in a separate document; this change was raise don the mailing
list and there were no objections. So it can move forward without
group keying. We can create a new draft-ietf-trill-group-keying, which
is not complete yet. And finally we can reference this new draft from
TRILL Over IP.  That’s our plan to go forward if the WG has no
objections. Any thoughts:

Bob: I don't know if this is right or wrong but is the problem that
there is no group keying? Is it hard? I spent some years working on
group security. It's not easy. Is that the problem?

Margaret: Well, we want to get it right and get good Security
Directorate review. Both of these drafts work without group
keying. You just use serial multicast but that is less efficient. So
we don't want to hold them up but we do want to get the efficiency of
group keying...

Sue: Are there group keying mechanisms specified and well liked in the
Security Directorate?

Bob: I just found an excellent presentation on all the group keying
standards. Would you like me to send that to you.

Margaret: Yes, that would be very useful. ... We need to pick a
mechanism and say have it applies.

Bob: A final point, you need to be careful to note that when you do
group keying, you can only authenticate that a message came from
another group member, not which one.

Margaret: Right. We just need to authenticate that it was an authorized
sender.  ...  [discusses draft flow slide]  ...  Next steps. [see
slide]  Any objections or thoughts on this plan?

Alia Atlas (AD, Juniper): Sounds like a fine plan. Just be sure to get
early SECDIR review.

Margaret: That's a good idea for the group keying draft so there is no
last minute surprise.

Sue: It would be good to provide information on the mailing list. It
should be a WG decision.

Donald: We actually did ask for early SECDIR review of the drafts
before and Yaron Sheffer did a review of Channel Tunnel which kind of
blew up the previous group keying in the draft and pointed out how bad
it was, which led to taking it out. He also did a review of TRILL Over
IP when there wasn't any group keying in it. Hopefully he will
continue to be involved. I'm about to ask him to review the Channel
Tunnel draft again now that group keying has been taken out.  ...  He
then seems like the logical person to review the group keying draft.

Margaret: Sounds like there is general agreement in the room. We
should also check on the list.

Sue: You should focus on getting the group keying draft out.

Margaret: OK.


Sue: For the next presentation, is it Mingui or Donald?

 20 min.  Multi-Topology / Multi-Level TRILL, Mingui Zhang, Donald
 ===========================================
 Eastlake, Radia Perlman, draft-ietf-trill-rbridge-multilevel-01,
 draft-ietf-trill-multi-topology-01,
 draft-ietf-trill-multilevel-single-nickname-01,
 draft-zhang-trill-multilevel-unique-nickname-00 

Donald: For this presentation, you get two speakers, first me, then
Mingui. [see slides] Status of drafts ...  The Informational
trill-rbridge-multilevel is past WG Last Call ... it talks about
various options.  One of the biggest is whether the nicknames across a
multilevel TRILL campus are unique or aggregated for level 1
areas. The informational draft suggests you should support
both. ... Unique is simpler but could run out of nicknames in a very
large campus. ... Aggregated avoids running out of nicknames but
involves more complex manipulation of TRILL Data packets as the level
1 / level 2 border.  ...  The "single nickname" draft uses
aggregation. ...  The multi-topology draft is in fairly good shape.
...  The next presentation is on the "unique nickname" draft.

Mingui Zhang (Huawei): This draft achieves multilevel TRILL with
unique nicknames.  ...  The border RBridge between level 1 and level 2
needs to do some additional things.  ...  announce nicknames ... Route
is calculated segment by segment in each area.  ... unicast example
... Multi-destination local distribution trees and global distribution
trees.  ...  Global distribution tree also calculated segment by
segment.  ...  [extensive details on multi-destination forwarding] ...
One possible problem: nickname re-use is not allowed between unique
nickname areas. The question is, is nickname re-use allowed between
unique nickname area and an aggregated nickname level 1 area. The
answer is no. ... [the reason is that a border RBridge to such an
aggregated level 1 area would be confused for such a nickname re-used
in a unique nickname area] ... Next step: We will incorporate comments
we have received. Then we think it is ready for WG adoption.

Yizhou: I remember this unique and aggregated nickname was discussed
before.  I have not read this draft. Aggregaged is already a WG
draft. Is there an explanation in this draft as to why we need unique
nicknames? In my mind, aggregated nicknames were already pretty well
settled.

Mingui: Each has its own features.  Aggregated nicknames requires more
complicated border RBridge since it has to re-write nicknames but it
allows a bigger campus. Unique nicknames is simpler but, because
nickname re-use is not allowed between the areas, that means the TRILL
campus cannot be very large.

Yizhou: OK. I'm not really questioning that, just that this sort of
justification should be included in the draft. A follow-up question:
Since the aggregate nickname is already adopted, is there a
requirement that a border RBridge support both? ... Is there a
mandatory upgrade requirement if we introduce this unique nickname?
The draft should say something about this.

Mingui: Yes if, we have border RBridges that only support aggregated
nicknames and we add unique nicknames, some change would be needed at
the border.

Yizhou: So what would happen? Some text is needed on this. Also about
compatibility with legacy RBridges that don't support either
aggregated or unique.

Donald: That's all good things that we should cover in the draft but
basically if there are border RBridges that support aggregation and
you add a border RBridge and level 1 area using unique nicknames
elsewhere in the campus, it doesn't require any change. To the border
RBridge supported aggregated nickname the other border RBridge
supporting unique nicknames and all the unique nickname in the other
level 1 area all just look like part of a bigger level 2 area.  ...
Basically existing cheap merchant silicon does not support nickname
re-writing. So if someone wants to do a small multi-level campus with
lower end TRILL switches and aggregation, then they have a problem
because aggregation is not supported in the fast path. On the other
had, if they are using network processors or high end stuff, there is
no problem.  So I think border RBridges can support one or the other
or both (with some software tweaks) but they need fast path support.

Yizhou: OK. So there should be some guidance to implementers to
clarify this.

Sue: Any other thoughts about this? [no response]


 12 min.  TRILL Charter Revision, Jon Hudson
 ===============================
 
Jon Hudson (Co-Chair, Brocade): [see slides] Before I get started I
wanted to mention that this afternoon at the Routing WG I'm going to
do a quick presentation on TRILL. ...  Today we are going to talk about
some things with a possible presentation of a new Charter in Berlin and
adoption thereafter. ... [review of charter work items and their
completion status] ... On the security analysis item, is this
critical?

Donald: All our RFCs, of course, have Security Considerations sections
in the. I think this work item was added to the Charter some time ago
because it seemed like a good thing but it was never really clear. I
think in earlier versions of the Charter, it specifically said
Security of IS-IS for TRILL. TRILL is deployed. No one has ever
complained about the security of TRILL or said it was insecure. So the
point with this work item was never clear. ...

Jon: So you are saying that since he have dealt with security of the
various items, we don't need an overarching security review?

Donald: More or less. To some extent TRILL security depends on IS-IS
security and IS-IS security is not perfect so I'm sure TRILL security
is not perfect but it isn't our place to work on IS-IS security.

Sue: I think with group security, we will have tied up any lose ends.

Margaret: I agree with Donald but want to say it more broadly. To have
a security item in the Charter implies that we think something is
wrong with the security. Security is always in Charter even with no
work item. ...  If someone came along with a paper saying TRILL was
insecure, it is not like we wouldn't look at it just because we didn't
have a security item in our Charter. Having a deliverable when we
don't really know what to write seems silly.

Alia: I sort of agree. Security is always in Charter. And there has
been absolutely no issue with the Security Considerations part of any
of the TRILL drafts I have progressed. I am not convinced you need to
retain this in the Charter except in a "TRILL Maintenance including
Security" sense. This is just off the cuff but you might want to think
about Privacy Considerations.

Jon: That's a good point. Any other comments on security? ...

Jon: Idea is to drop completed items and add some new items. We are
thinking about adding a Traffic Engineering item and adding a
Transparency item to reduce couple between TRILL and attached
networks.  One nice thing about having a protocol that has calmed down
is that you in this room have a lot of say as to where this goes. We
want it to go where you want it to go. ... Please speak up.

Jon: Another possibility is to change the name behind he acronym. We
don't want to change the acronym but we have been playing around with
different ways of filling it out [see examples on slide]

?: Could you say why you want to do that?

Jon: Over time there has been some consistent flow of comments that
TRansparent Interconnection of Lots of Links does not clearly define
what we did here and causes some confusion.

Jon: Ok. That's it. ...  Any further comments on the Charter?

Yizhou: ... Can we suggest new items for the Charter on the mailing
list?

Sue/Jon: Please do. This is your protocol. ...

Alia: Re-chartering is not hard unless there is lots of disagreement.
Otherwise, you just push a few buttons. TRILL is becoming pretty
mature. But it should be stuff needed to support the deployments and
types of use out there, not just stuff that seems like it would be
cool.


  6 min.  Wrap-Up, Chairs
  ===============

Jon: Alright, unless there are any further comments or concerns I think
we are done for the day. ... Thanks for coming and thanks for all your
hard work. We will see you all in Berlin. ... And we are done.