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

IETF 93 TRILL Working Group Meeting Minutes
===========================================
Hilton Prague, Prague, Czech Republic
Date: 7/23/2015  Session: 15:20-17:20

Minutes by Donald Eastlake (Huawei), TRILL WG Secretary
Reviewed by Sue Hares (Hickory Hill Consulting)
   and Jon Hudson (Brocade), TRILL WG Co-Chairs

Times given are those originally scheduled, not necessarily the time
things actually happened.

Sue Hares (Hickory Hill Consulting): [See Agenda and Milestones slide
presentation] This is the TRILL WG.  ... (introduce WG Officers) ...
Alia Atlas sends her apologies. There was an I2RS meeting that either
she or I had to attend. I'll go through the agenda, we can bash it,
then we have a lot of interesting presentations.

Agenda bashing                [15:20-15:25]
Status                        [15:25-15:35]
===========================================

Sue Hares: ... RFCs ... 5 documents in publication requested state
... please read the drafts, we welcome input ... we are in WG Last
Call for Tree Selection and we have other drafts coming up. Please
read and comment.  Also several draft in call for adoption, including
the multilevel and multi-topology. ... We have been working on
active-active and directory assistance and the core of those have been
approved ... We have completed most of our milestones but we have some
overdue milestones - quality can take times. ...


TRILL Traceable OAM           [15:35-15:47]
===========================================
draft-yizhou-trill-traceable-oam-00

Yizhou Li (Huawei): [see Slides] [some jokes about adjusting
microphone and the pink box] ... motivated by centralized management
server that can feed in test messages ... optional feature to
supplement ping and traceroute. Fits into current Data Center
deployment.  Centralized controller usually created by customer who
wants to do their own analysis. ... Centralized analysis frees sending
and receivers of OAM from doing the analysis. Typically Centralized
controller has more compute power. ... All that is needed is a
"traceable" (T) flag in TRILL OAM header. Only valid in PTM (Path
Trace Message) and MTVM (multi-destination tree verification message).
Flag indicates that transit RBridges are to replicate the packet to
the CPU and have the CPU perform different behavior from traditional
OAM. For example, use packet-in to send to central open flow
controller. Transit RBridge might also add local interface identities,
etc. Also, sender does not expect responses so time out can be turned
off. ... For MTVM, may only want to test to egress nodes. Pure transit
nodes of no interest in that case. ... Comments and suggestions
welcome.

Weiguo Hao (Huawei): You want to introduce flag in the TRILL Header to
indicate packet should be delivered to the open flow controller?

Yizhou: It is in the OAM Header, not the TRILL Header.

Weiguo: OK.

Jon Hudson (Brocade): Thanks for the clear slides.

Sue: Jon just reminded me need a scribe.

Donald: I'm being scribe, as WG Secretary, but not a Jabber scribe.


TRILL Over IP                 [15:47-16:02]
===========================================
draft-ietf-trill-over-ip-03

Margaret Cullen (Painless Security): [see Slides] ... treats IP
connection as a link type ... Between draft versions -02 and -03, we
have added VXLAN encapsulation because we were told how important fast
path support is and VXLAN fast path support is deployed. There is also
a signaling mechanism to select the encapsulation and that is now in
the draft. ... We have added some QoS in the form of priority to DSCP
codepoint mapping and specified mandatory to implement IPsec
algorithms.  ... Encapsulation choice factors ... one size probably
does not fit all. Fast path support is quite important. ... Simple UDP
encapsulation as in previous draft is required to be implemented.
... Two modes, either dynamically determined encapsulation or
statically configured encapsulation. ... UDP ... VXLAN ... There are
other encapsulations. ... Question: do we want to include any of them
in future versions of this document or other future documents?  Do we
need to support these? Do we want to put them into this draft? What
does the WG think?

Sue Hares: Is there anyone who thinks we will want to support any of
these other encapsulations?

[inaudible] ... Generic UDP Encapsulation [GUE] ...

Donald Eastlake: These encapsulations differ in various ways.  Some of
them have variable length fields which leads some people to think they
will be less likely to have fast path support.  But obviously they are
more flexible.  I think it might be better to just put out the
document as it is now with UDP and VXLAN and put other encapsulations
in other documents when we are sure there will actually be fast path
support for them. Some people may have network processors than could
do any of these. But most data center switches are using merchant
silicon that supports approximately one encapsulation that would be
suitable.

Margaret: So maybe we should wait until people come to us and say we
have hardware support.

Donald: Or they say hardware support will ship on date X.

Margaret: Does that make sense to the WG?

Deepak Kumar (Cisco): Some of these encapsulations are not even take
up by NVO3. But we know that VXLAN is already there. We should wait
until other encapsulations are in the silicon.

Jon Hudson (Brocade): I'll agree with that. VXLAN has a document.
... I admit some bias as I am an co-author of GENEVE. This is not
going to end anytime soon.  There will be new encapsulations coming
out after none of are involved in this anymore. To assume we can
document them all is unreasonable.

Margaret: We could make the flags field an IANA field and allocate
bits for other encapsulations later. ... Support is indicated by
repurposing part of the RBridge Channel protocol number space. How
many of them are there?

Donald: Well, the value is a 12-bit field so there are 4K values. 48
are re-assigned for "link technology specific flags" and for IP
technology links, those flags represent encapsulations. And if we had
more than 48 encapsulations we could allocate more bits. Any bits not
specified are assume to be zero. The encoding is quite efficient and
these bits appear in Hellos.

Margaret: Well, I hope we don't have a protocol with 48 different
encapsulations. That would be a bit scary. ... Different ports might
support different encapsulations due to part hardware. ... TRILL uses
8 priority levels ... map to DSCP values. Default mapping in -03
draft. ... Draft now say so use IPsec ESP tunnel mode due to existing
hardware support. Currently uses keys derived from IS-IS keying. ...
Since this draft, we have talked to the Security Area and they have
assigned Yaron Sheffer to help us. He has started to look at our
document but we don't have much to report yet. He has suggested we
could derive our keys in a different way for more security so if your
IS-IS keys were compromised you wouldn't lose all your other keys.
There is some question if we want to use IKEv2. I think we should
report on that next time. There should probably be some discussion on
the mailing list.

Sue Hares: It would be good as you get that review to shot it out to
the mailing list.

Margaret: Sure. Once we understand it well enough. ... But he says he
will post his comments to the list. Did that happen?

[inaudible]

Margaret: OK, I just haven't seen it yet. ...

Lucy Yong (Huawei): You can use IPsec if you want but if you do you
lose the ability to add entropy that you have with UDP. The UDP source
port would be encrypted. That is why people are using DTLS. ... DTLS
leaves the UDP header visible.

Margaret: Yes, we had DTLS in the draft but the WG reached consensus
to move to IPsec so I'd be surprised by a sudden consensus to switch
back. We presented the trade-offs to the group and the group decided
to switch to IPsec to support external appliances and due to the
hardware support.

Sue: And the last point was thing in Honolulu. We had vendors that
came in and said we really need the hardware support. Switch from UDP
to VXLAN and from DTLS to IPsec.

Margaret: I disagreed with that initially but I was won over by the
arguments.  They should be in the minutes.

Jon Hudson: And that doesn't mean that this is the end of the
discussion.  I have seen a lot of interest in multi-hop MACSEC.  So we
may be able to do more things later but for this draft, IPsec is the
thing.

Lucy: That's fair.  I just wanted to point out the difference. If
entropy and the use of multi-path is the priority then IPsec is
fine.

Margaret: ... We have been working on this draft for a long time. I
think it is important that we get this draft out. Then there is no
reason we can't work on new encapsulations or other ways to secure
TRILL over IP later.  We have had people in the room who want to
implement this with VXLAN and IPsec.

Lucy: All these encapsulations use UDP. Before you publish this you
may need a cross WG check with TSV.  Once you do this encapsulation,
it is running as a UDP application, not as a TRILL application. So
there are additional requirements. There are requirements for running
over IPv6. Also, once you are using UDP, you can run over middleboxes.
With just TRILL, there are no IP middleboxes. With IP, there are
middleboxes.

Margaret: We want to work over middleboxes. There is the remote office
scenario. Maybe the Chairs can check. I haven't heard of a requirement
to be last called in TSV.

Lucy: The middlebox issue is separate from the congestion issue. And
checksum is another. Three things.

Margaret: But I don't think we have any problem with those things. Can
the Chairs check with Alia [TRILL WG AD] and see if there is something
we need to do.

Sue: I'll check.

Lucy: This is for standards track right?

Margaret: Yes, I know we will get a Transport Area review but I don't
think there is any requirement that it be last called in TSV.

Lucy: Where is this in process?

Sue: It is getting close to WG Last Call so this is a good time to
bring up this issue. I can talk to the Transport ADs and to David
Black.

Lucy: I think it you get transport review and review by David Black,
that would be good.

Sue: Donald, please note this as an action item.

Jon: The Transport Area is already doing some things in this area with
encapsulation considerations.

Lucy: You also propose VXLAN so you have this VNID (Virtual Network
Identifier) field. What is the proposal for how to treat that field?
Sorry I didn't read the draft.

Margaret: Donald wrote that part of the draft.

Donald: I don't think it is in the slides but basically it is part of
the TRILL over IP port configuration to either use a fixed VNID or to
map the VLAN or Fine Grained Label into the VNI.

Lucy: So this is addressed in the draft.

Donald: Well, the draft isn't complete so I'm not sure how well it is
addressed in the draft. I believe the draft says what I just said. It
could be that it needs a bit more detailed. Reviewing the draft and
giving comments would be a great thing to do!

Sue: We will send you the section of the draft and ask for your
review.

Weiguo Hao (Huawei): I think the TRILL neighbors should negotiate the
VNID to ensure consistency.

Margaret: Send text please.

Sue: Can I ask a favor? Could you post the three concerns to the
mailing list? Checksum, Congestion, and Middlebox.

Margaret: Those are the big three.

Sue: Thanks for bringing these up. We want a conversation on the
mailing list.

Margaret: ... Additional encapsulations. I think people want to go
with the current draft.

Sue: You can take that as the consensus of the room. We can always
issue another document later.

Margaret: Material will be added on the security configuration and
require that derived keys not be used beyond the lifetime of the keys
from which they are derived. ... Middlebox. ... Draft needs
re-organization.  Any other big things left out of the draft before we
can go for WG Last Call?

[no response]

Sue: What's your schedule?

Donald: Well, I think we maybe need 2 revisions of the draft so maybe
about two months.

Margaret: So maybe before the next IETF meeting. Any further feedback?
[no response]

Sue: OK. And thank you again Lucy for bringing up these topics.


Trill Link security           [16:02-16:14]
===========================================
draft-eastlake-trill-link-security-01

Donald Eastlake (Huawei): [see Slides] ... The draft is an early,
incomplete draft. It needs more work. Draft goals: ... To establish
strong security policies and defaults for TRILL link security, to
specify security more precisely for links. TRILL is really a layer
3ish protocol, although under IP. ... TRILL over Ethernet is covered
by the TRILL base protocol RFC and TRILL over PPP and TRILL over
pseudowire have their own RFCs. Finally, TRILL over IP is being
covered by the draft we just talked about. But, for the first three,
the link security specification is not very prices. Also, the draft
cover edge-to-edge security. ... ... ... This draft needs more
work. Any questions?

Jon Hudson: I just want to note that those of us working on this sort
of thing think that in the future there will be layers upon layers of
security and frameworks like this help us start building that and are
very important not just for TRILL but for all of our protocols.


TRILL over VPLS/MPLS          [16:14-16:26]
===========================================
draft-muks-trill-transport-over-mpls-00

Lucy Yong (Huawei): [see Slides] ... I'm new to this WG and came to
this meeting for this draft. The primary author is not able to attend
this meeting and asked me to give this presentation. How much time do
I have?

Sue Hares: 15 minutes.

Lucy: Good. ... This draft defines two ways to interconnect a TRILL
campus.  One is Virtual LAN service [VPLS] the other is a new Virtual
TRILL service [VPTS]. Problem is you have multiple TRILL sites and
need to interconnect them. Also we may have multiple tenants and you
need to connect them as separate TRILL domains. ... Two solutions, one
uses existing VPLS ... multipoint virtual service over MPLS ... at
edge attachment circuit to customer on one side and pseudowire on the
other. ... really no change to use VPLS to interconnect TRILL. VPLS
looks like a bridge and TRILL already works with bridges. Just connect
RBridges to the VPLS edge. No change in VPLS and MPLS control plane.
VPLS looks transparent, just processes traffic as layer 2 frame, does
not even see that it is TRILL traffic. ... New model Virtual Private
TRILL Service [VPTS]. Provides TRILL service rather than LAN service.
Edge switch can run TRILL protocol as well as VPLS protocol. ... Have
a virtual RBridge on the PE instead of a VSI. ... So we provide two
models, VPLS and VPTS. ... Both model need no enhancements to existing
VPLS control plane.  ... Next step - this is a new draft. ... I really
encourage people to read this draft. ... Need to add hierarchical VPLS
and add pseudowire redundancy consideration. VPLS interworking with
VPTS.  Define behavior of Virtual TRILL Service Domain. ...

[Audio file appears to end here, following material has not been check
against a recording]

Sue: I'm sorry but we are running short on time so please keep the
remaining presentations short.


Distribution of TRILL Link-State Using BGP
draft-hao-idr-trill-ls-01     [16:26-16:38]
===========================================

Weiguo Hao (Huawei): [see Slides] ... Primary motivation is getting
TRILL link state information to SDN or other central controller.
Extend BGP link state to support TRILL link state and support MAC
address reachability information. ... New Protocol-ID for TRILL.
... New MAC Reachability NLRI (Network Level Reachability Information).
... Opaque Node Attribute TLV used for some TRILL specific
information.  Add Link MTU to Link Attributes.  ... Add gateway bit to
node flag bits.  ...  Seek comments and feedback.  Seek adoption in
the IDR WG.

Sue Hares: This is to be presented Friday in the IDR WG but it affects
both TRILL and IDR so I wanted it presented here first. Is there any
objection to this draft going through the IDR WG?  [no objections]


Multi-Level / Multi-Topology  [16:38-16:58]
===========================================
Multi-Level TRILL
draft-perlman-trill-rbridge-multilevel
draft-zhang-trill-multilevel-single-nickname
Multi-Topology TRILL
draft-eastlake-trill-multi-topology

Donald Eastlake (Huawei): [see Multi-Level TRILL slides] ... The
perlman-trill-rbridge-multilevel draft is mostly a survey of different
approaches. ... TRILL multi-level uses multi-level features of
IS-IS. ... advantages ... unique nicknames versus aggregated
nicknames ... draft suggest a hybrid where some level 1 areas can use
unique nicknames while others can be aggregated. ... This draft is
currently in call for WG adoption. Questions? [no response]

Donald: [see Single Border RBridge Nickname slides] ... Several
improvements in this version -01 draft from the -00 draft. ... Improve
multicast forwarding. Specify behavior when a border RBridge is
connection to multiple areas. ... Next steps, ask for WG
adoption. Questions? [no response]

Donald: [see multi topology slides] ... Multi topology creates
different physical subsets of the links and TRILL switches in a TRILL
campus. traffic in a topology is constrained to such a subset.  ...
TRILL multi topology is based on IS-IS multi topology in RFC 5120.
... There is a special topology zero while includes all links and
switches - useful for management functions. ... Provides for explicit
labeling of the topology of a TRILL data packet although topology is
usually implicit -- based on existing fields such as VLAN, IPv4/IPv6,
DSCP codepoint, etc. ... Questions? [no response]


Wrap-Up                       [16:58-17:05]
===========================================
Sue and Jon: OK. Thanks for all the excellent presentations. Sorry we
ran a few minutes over but I think it was worth it.  See you on the
mailing list and in Yokohama.