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

TRILL Working Group Minutes - IETF 92
The Fairmont Dallas, Dallas, Texas

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

Date:   Wednesday, 25 March 2015
Room:   Royal Room
Time:   13:00 - 15:00

Note: Times listed are the time originally scheduled for the item, not
the amount of time it actually took.
 
 5 min.  Administrativia (scribes etc.), Agenda Bashing, Chairs

Jon Hudson (Co-Chair, Brocade): Blue sheets going around, please
sign. Let's get started. Sue is our co-chair and Donald is our
secretary. Ted Lemon, who is our AD for the rest of this week is also
here.

Jon Hudson: The Note Well should be read and understood. Ask if you
have questions about it. ... [goes over agenda, see slides] ...

10 min.  Document Status,
         Review of Milestones, Chairs

Sue Hares (Co-Chair, Hickory Hill Consulting): ... [goes over document
and draft status, see slides] ... Please read the drafts. We expect to
forward the YANG drafts and Directory Assist drafts for publication
fairly quickly. The only milestone we are overdue on is the TRILL over
IP draft to IESG.

Donald Eastlake (Secretary, Huawei): So, I have three quick status
presentations, the first on active-active.

 6 min.  TRILL Active-Active Status/Summary
            Yizhou Li, Tissa Senvirathne, Hongjun Zhai, 
            Weiguo Hao, Mingui Zhang, Donald Eastlake
         draft-ietf-trill-aa-multi-attach-03
         draft-ietf-trill-cmt-06
	 draft-ietf-trill-pseudonode-nickname-04
	 draft-ietf-trill-centralized-replication-01

Donald Eastlake: [Presentation: Active-Active Status, see slides]
[comment on how high the microphone was set] Idea is to extend the
rapid fail over and traffic spreading on a per flow basis that TRILL
provides inside the TRILL campus to multiply connected end stations /
bridges at the edge. RFC 7379 give problem statement and goals. There
are three alternative ways to doing this.  ... We are progress two of
these, pseudonode nickname and multi-attach.  ... [review the
trill-pseudonode-nickname, trill-cmt, and trill-aa-multi-attach draft
that are being advanced now] ... draft dependencies ...

Sue Hares: By the way is there anyone for whom this is their first
TRILL WG meeting? [a few hands go up] Welcome! Please do not hesitate
to ask questions if anything is unclear to you.

 5 min.  Directory Assisted Edge Status
            Donald Eastlake, Linda Dunbar
         draft-ietf-trill-directory-assist-mechanisms-01
         draft-ietf-trill-ia-appsubtlv-02
         draft-ietf-trill-directory-assisted-encap-00
         draft-yizhou-trill-arp-optimization-01

Donald Eastlake: [Presentation: Directory Assisted Edge Status, see
slides] ... push and pull directories of address information and
location ... can be used for ARP/ND optimization ... complete
directory info can be used to eliminate unknown MAC flooding and
protect against spoofed source addresses ... push directory uses ESADI
while pull directory uses query/response ... [review of draft status,
contents, and dependencies] ...

 9 min.  RBridge Channel Tunnel, Donald Eastlake
         draft-ietf-trill-channel-tunnel-04

Donald Eastlake: This is the last of the three quick status
presentations.

Sue Hares: Anyone new here from the Routing Area? Some of these
directory assistance ideas are now being suggested in other RTG WGs.

Donald: [Presentation: RBridge Channel Tunnel, see slides] ...
[background of RBridge Channel messages] ... Channel Tunnel adds
security. The basic RBridge Channel facility does not provide
security.  We got dinged a bit by the Security Area when RFC 7178 went
through but we got it through and it isn't a problem for something
like BFD that has its own security. But this is not always true and we
want to be able to security pull directory messages.  ... [details of
Channel Tunnel] ... Channel Tunnel is almost like an extension to the
RBridge Channel facility. Changes since last meeting are to add
security and remove the "Scope" feature that was too complex and had
no demonstrated need. Channel Tunnel can bootstrap off IS-IS keying
for security with zero additional config. ... [discuss payload
types] ... Currently payload types for RBridge Channel message, TRILL
Data packet, and TRILL IS-IS packet do not start with an Ethertype but
one exists for each of these.

Donald: Question: Can we collapse these three payload types and to one
where we say it starts with an Ethertype? Will ask on the list also.

Hao Weiguo (Huawei): If you collapse these three types into one, do
you need to define an Ethertype to distinguish type 5?

Donald: No. There is still a separate payload type that can indicate
Channel Tunnel payload type and there is a Ethernet frame type.

... [explanations of message structure based on slides] ...

Donald: We need to resolve the above question. I'll post a question to
the list. Then it needs just a little polishing and I think the draft
will be ready for working group last call.

12 min.  Tree Selection, Yizhou Li
         draft-yizhou-trill-tree-selection-04

Li Yizhou (Huawei): Wow, this microphone is really high and I'm short.
[Presentation: Data Label Based Tree Selection, see slides] This was
previously called "VLAN based" but we wanted to be more consist with
other TRILL document so we changed it to Data Label.  ... [give
background] ... motivation is to save precious space in fast path
multicast tables ... highest priority tree root announces data labels
allowed on each tree ... [example] ... Updates from last revision are
to change from "VLAN" to "Data Label", sub-TLVs are put into E-L1FS
FS-LSPs, and re-used the Group sub-TLVs defined in RFC 7176 to give
group limitation. Next step: authors think this draft is ready for WG
adoption.

Sue Hares: How many people have ready this draft? OK. People are
encourage to read the draft and ask questions on the list. We will
probably do a call for adoption soon.

12 min.  Revision of Appointed Forwarder RFC, Donald Eastlake
         daraft-eastlake-trill-rfc6439bis-00

Donald Eastlake: [adjusts microphone height] ...

Donald: [Presentation: Revision of Appointed Forwarder RFC, see
slides] ... Title slide has a typo, should say "rfc6439bis".  ...
[gives background] ... One change in this bis version is to add
mandatory support for E-L1CS FS-LSPs (defined in RFC7356] to increase
available local "link state" from a single Hello to 65K fragments.
...  Currently all appointed forwarder information has to fit into
one Hello. ... Now specifies some APPsub-TLVs for more efficient
encoding of appointed forwarder information. ... When we specified
Fine Grained Labels, we got dinged a bit by Adrian Farrell who though
there should be a consistency check on the mapping between VLANs on a
link and FGLs because it would cause problems if they were
inconsistent. This draft adds such a check optionally. ...

Donald: There are two categories of possible future improvements to
forwarder appointment in this draft.  These are both aimed at making
the appointed forwarder mechanism more responsive. These would be
optional enhancements. There is IPR is both and IPR declarations will
be filed. First, you might have an RBridge that is planning to shut
down but is currently handling the traffic for some VLAN. It would be
nice if it could tell the other RBridges on a link that it is going
away.  Or an RBridge might detect that a link has failed. In some
cases you can detect this at the physical level. Currently that is
only noticed by other RBridge on the link if they miss getting three
Hellos in a row, which can be many seconds. So, the idea is that the
RBridge going down or which has detected link failure can send a
message to the other RBridge on the link.  If the link [actually port]
is down, it can serially unicast to the other RBridges through the
TRILL campus since typically they are richly interconnected. Or if it
is going down and the link is still up, it could broadcast that it is
going down on the link. When an RBridge receives one of these
messages, if the sender was the Designated RBridge for the link, it
switches to a different DRB. And if the DRB receives this from an
RBridge with is an Appointed Forwarder it designates some other
Appointed Forwarder for the VLANs that RBridge washandling. ...
Second, if a link is a bridged LAN with a bridging protocol running.
... If there is a topology change inside the bridged LAN, it
takes some amount of time for the bridging protocols to settle. If two
bridged LANs merge, you could have two Appointed Forwarders for the
same VLAN which can cause loops. And while the bridging protocol is
settling, Hellos might not get through. ... Current TRILL policy on
this is very conservative. ... When a root bridge change is seen, a
port is inhibited for a while.  ... But it turns out there are cases
where you don't have to do that.  ... [describes the three cases] ...
So all of these are optional enhancements that make the appointed
forwarder mechanism work faster and better but you don't have to
implement either. Both have IPR. I believe there will be two IPR
declarations filed. I'd like to put these into the draft and get the
IPR declarations posted. Then people can read the declaration and
comment if they want. ...

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

Margaret Wasserman (Painless Security): [Presentation: TRILL over IP,
see slides] Treats an IP network as a link connecting TRILL switch
ports. There are two scenarios in the draft ... Changes from the last
draft were primarily motivated by feedback that the previous draft
wasn't designed to make good use of existing hardware for security and
encapsulation. ... On security we changed from DTLS to IPsec. ... For
encapsulation we got feedback that being able to use VXLAN would be
better.  ... [more details on IPsec] Still need to specify default
crypto algorithms. We use ESP Tunnel Mode ... The current draft only
specifies UDP encapsulation. But there is better fastpath hardware
support for VXLAN, which is really TRILL over Ethernet over VXLAN over
UDP/IP. Other encapsulations are being developed. ... The initial
exchange can be in TRILL over UDP and then you could negotiate what
encapsulation both RBridges are willing to support and only establish
adjacency if there is an encapsulation in common between them.

Sue Hares: So this would be TRILL over IPsec over UDP.

Margaret: Yes, if you were using IPsec. ... Other work remaining: QoS
considerations and middle box considerations. ... Feedback and
questions welcome. ...

Hao Weiguo: You have two TRILL over IP encapsulations, one is TRILL
over UDP the other is TRILL over VXLAN. If the first only supports
P-to-P... I know TRILL over VXLAN supports both P-to-P and broadcast
...

Margaret: No. We are putting the VXLAN encapsulation in and it is not
fully specified yet. I believe it will probably support both but I think
TRILL over UDP also supports both point-to-point and broadcast.

Donald: Sure, in TRILL over UDP if the TRILL packet is
multi-destination, the IP address would be multi-cast.

Weiguo: For broadcast link TRILL is over multicast IP header.

Margaret: Yes, it is TRILL over UDP so it could be over whatever link
type IP can run over. Say it was Ethernet, that has broadcast so the
packet could be broadcast. If it is over a point-to-point link it
would be point-to-point, right?

Weiguo: The IP link is similar to normal link between RBridges. How to
simulate a broadcast link using an IP header. I think it is easy to
simulate a point-to-point link. I think for VXLAN it is easy.

Margaret: For broadcast you just use a multicast IP header. I don't
understand why you think they are different.

Donald: That is one reason we added section 6 on configuration. By
default, the port just does some obvious thing like using a standard
multicast group. For examlpe, for Hellos, you would normally want to
multicast because you are looking to see if there is anything out
there that might send a Hello back to you. But, if you want, you can
configure a list of unicast [IP] addresses and when it wants to send a
broadcast it would just send it to the list of unicast address. That
list could have just one member if you want to configure it to be
restricted like that. But by default it blasts it out to an IP
multicast address.

Margaret: Don't we have an All-RBridges IP multicast address?

Donald: We only have an All-RBridges MAC address. The draft does ask
IANA for both an IPv4 and an IPv6 multicast address but it hasn't been
allocated yet.

Margaret: So you could use that or use the unicast list where you want
to restrict it.

Donald: Right, or if multicast was not supported. If the RBridges are
just randomly on the global Internet, there probably isn't multicast
service so they would need to use unicast.

Margaret: In the remote office case, you are probably going to use
unicast because you are just trying to connect to that office. You
don't want to ask everyone to be a remote office.

Jon Hudson: It's a tunnel. Were you asking if VXLAN is different than
just using UDP?

Weiguo: I think the second encapsulation is easier to be implemented.
Neighbors relationship is very similar to normal TRILL protocol with
the second encapsulation. UDP seems different...

Jon: We don't want to frustrate you. Maybe you can post your question
to the list?

Weiguo: OK.

Margaret: Maybe you can explain on the list why you think they would
be different.

Donald: Maybe we should include some example packets in the draft.

Margaret: Sure, we can do that.

12 min.  TRILL Link Security, Donald Eastlake
         draft-eastlake-trill-link-security-00

Donald Eastlake: [Presentation: Link Security, see slides] I managed
to get a very early -00 draft posted before the IETF meeting. ... Goal
is to establish a strong security policy and defaults for TRILL link
security.  ... Draft is intended to cover Ethernet, PPP, and
Pseudowire links, refers to TRILL over IP draft for IP links.  ...
Possible addition would be to cover edge-to-edge security, between the
ingress and egress TRILL switch. This is just a personal draft right
now but I thought people might be interested. I plan to add the
edge-to-edge security.

Jon Hudson: From my point of view, that would be good to add.

Donald: Proposed action: work on the draft

Jon: One thing to keep in mind is that with all the current interest
in security, bringing this into TRILL should be a good opportunity to
help end users with their fears about security ...

15 min.  Multi-Level TRILL, Mingui Zhang, Donald Eastlake
         draft-perlman-trill-rbridge-multilevel-09

Mingui Zhang (Huawei): [Presentation: Single Border RBridge Nickname,
see slides] This draft specifies a solution for TRILL multilevel.  ...
Why multilevel ... A major issue is how to manage nicknames. ... There
are three alternatives, Unique Nicknames, Aggregated Nicknames, and
our Single Nickname - Multiple Level proposal. ...

Hao Weiguo: Does the TRILL encapsulation need to be terminated at the
border RBridges? Is MAC switching required or just nickname?

Mingui: It depends. On level 1 to level 2, just nickname needs to be
changed. For level 2 to level 1, a MAC lookup is needed.

Weiguo: How does the level 1 to 2 border RBridge know where the
destination level 1 area is?

Mingui: It was learned from earlier traffic in the other direction.

Li Yizhou: But that earlier traffic might have different level 2 to
level 1 border RBridge nicknames... Is there a flip-flop problem.

Mingui: Yes, if might come through a different border RBridge. But
when there is reverse traffic later, the border knows what nicknames
correspond to the destination area and can normalize to using the one
it wants.

Yizhou: In slides 9, the lightning represents a broken link. But what
if there is another RB5, say, in the right hand area connected to
RB30, then isn't the broken link a problem?

Mingui: But there is a tree inside the right area, root RB44, so the
traffic can get through.

Donald: There is a fully connected tree in the right area that had
better connect to this RB5. If RB5 only connects to RB30, then RB5 is
in a different area.

Weiguo: You use data plane learning. If control plane learning is
used, then ESADI should be run in each area.

Mingui: Yes.

 5 min.  Wrap-Up, Chairs
 
Chairs: OK. Thanks for attending. We will be following up on the list
on items that came up here. See you in Prague.