Minutes IETF99: trill
minutes-99-trill-00

Hilton Prague, Prague, Czech Republic
        Friday, 21 July 2017.
        11:50-13:20 Karlin III Room

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

(Times given are as originally scheduled, not the time actually taken)
(Jon Hudson, Co-Chair, attended remotely)

  3 min.  Administrativia (scribes), Agenda Bashing, Chairs
  ---------------------------------------------------------

Sue Hares (Co-Chair, Hickory Hill Consulting): Feel free to move up
  front. This will be an interactive session. We have 17 drafts to try
  to get through the IESG in 4 months.

Sue: See and read the Note Well. This is a new Note Well.

  5 min.  Status, Chairs
  ----------------------
See Slides.

Sue: We are going to try to get these drafts through. Donald and Jon
and I will help but it will also be very helpful if people do reviews.

Alia Atlas (AD, Juniper): No only are reviews helpful, it is also
helpful if authors are pro-active. When I do an AD review, if you are
responsive I can get the draft through IETF Last call and on the IESG
schedule faster. If you are no responsive, well, it can take a lot
longer.

Sue: Note we now have a new IESG so you may be getting new comments.
We need to respond to both older outstanding comments and new ones.
Donald or I can help you if you need it. It's a group effort. Ask if
you need help.

Sue: [reviewed document status in detail from the slides and gave some
      history]

  3 nib.  WG adoption of draft-rp-trill-parent-selection-03.txt
  -------------------------------------------------------------
             Ramkumar Parameswaran

Ramkumar (Brocade): I don't actually have a presentation but wanted to
  ask if this draft is adopted so we can advance it?

Sue: Yes, it has been adopted. The purpose for the delay in adopting
  was to acquaint all the authors of the adopted drafts that these
  drafts need to go to WG LC in 4 months.

 12 min.  Changes needed to TRILL over IP, Margaret Wasserman
 ------------------------------------------------------------
             draft-ietf-trill-over-ip-10.txt
[See slides]

Margaret Wasserman (Painless Security): [brief presentation on what
TRILL over IP is about, what the draft covers, what encapsulations it
currently specifies, the chronology of the draft so far, and then got
into outstanding issues]

Margaret: [zero IP header checksum] [congestion control] We have this
  problem in the IETF that when we have a tunnel, and TRILL over IP is
  basically a tunnel, it is hard to tell if the traffic being carried
  through that tunnel is congestion controlled. Traffic being carried
  by IP is supposed to be congestion controlled and TCP provides that
  but UDP does not provide congestion control. ... We will have to
  figure out what to say in the specification about this because it is
  very hard to tell what you are carrying.

Sue: The TRILL over UDP congestion control has problems because you do
  not know what application is using it.

Margaret: Yes this problem was original found in the UDP tunneling
  used in CAPWAP. We should probably go see what that draft says.

Sue: Yes, we both knew that from our CAPWAP work. Is there a solution?

Margaret: There is still no real solution because TRILL is tunneling.

Margaret: [ECN] RFC 6040 rules on tunnel handling of ECN. ... We propose
  to support ECN in the outer IP if TRILL is supporting ECN. But will
  not try to dig past the TRILL Header in the case where there is an
  inner IP supporting ECN when TRILL is not supporting ECN. ... Anyone
  have any comments on this?

Sue: Does anyone have any comments on this?

Ramkumar: For the case where you are just working with the control
  plane, does this impact it?

Donald: The TRILL control plane is IS-IS, which is all one-hop messages
so, no, it is not affected.

Margaret: [QoS] The TRILL 3-bit priority plus a drop eligibility bit
needs to be mapped into a DSCP value. We need to double check the
TRILL mapping against the latest RFCs.

Donald: They are coming up with a DSCP code point explicitly for low
effort and this might be appropriate to use for one case.

Margaret: There is variance in the treatment of DSCP values by some ISPs.

Alia: Something that seems obvious to us are not obvious to the
   readers of the document.  ...

Margaret: The person who is implementing our specification, should be
  able to understand it. It is the operation's staff that need the
  description in the draft that explains the variance.

Donald: Different providers may use different DSCP mappings. This is a
  more general problem. The draft indicates the DSCP mapping is
  configurable. We thought this should indicate to the operations
  staff that TRILL (like other protocols) might need this
  configuration.  However, if you go though multiple ISPs, who
  knows. We should add more words.

Margaret: If you are using TCP, you need a separate TCP connection per
  QoS provided.

Margaret: [TCP] Call "transport". Add framing. Performance tweaks. MTU
  can be less than campus-wide limit because a payload packet can be
  split across TCP packets. So we need MTU discovery to be extended to
  a shorter configurable lower limit.

Sue: How does this link to the TRILL MTU packets?

Donald: The MTU test packets are adjustable in size. If you are using
  something UDP based, then you need an MTU such that IS-IS link state
  packets will get through otherwise routing might now work. However,
  if TRILL is running over TCP then the TCP packets can be smaller
  than that as TRILL control and data packets can be split over TCP
  packets. ...

Margaret: It will allow us to support lower MTU links.

Margaret: [fragmentation] "we shouldn't have any" ...

Margaret: [NAT] ... Need to use static bindings and map source IP
  addresses of hellos before putting the address in a Neighbor TLV. We
  can't count on a NAT having a TRILL ALG (Application Level Gateway).
  Need keep alive messages ... Need outer UDP when using IPSEC to get
  through NATs.

Sue: Is this new technology, wording changes, or implementations?

Donald: There is an IPSEC in UDP RFC so we would just use that.

Margaret: It isn't new technology but it would change implementations.
  ... NAT configuration, need to specify keep alive messages.

Sue: Is it well-designed work?

Margaret: Lots of small changes that will work.

Donald: There are quite a few things here but each one is pretty
  straightforward and well understood. It's always a judgment call
  whether another WG Last Call is needed.

Sue: In this case one will be needed.

Margaret: We could say it - it just does not work over NAT; but that
  is probably not what we want to say.

Alia: The question is do deployments need this option? It adds complexity.

Margaret: The IP backbone / campus scenario would work without
  NAT. The remote office would likely need NAT support.

Alia: NATs are most common in IPv4. It is good to get feedback
  on the mailing list whether NAT support is needed. May not be needed
  for IPv6.

Donald: In the current draft we do recommend use of IPv6, mostly
  because IPv6 fragments are more robust. ...

Margaret: Do DSL providers support non-NATed V6? I will ask around.
  DSL is typically the case where the provider is NATing.

Alia: The regions where TRILL is deployed are more v6 centric.

Sue: Margaret please ask on the list regarding TRILL deployments about
  the NAT usage. ...

Margaret: The NAT is the largest potential addition to this
  specification. The rest of the changes are mostly editorial.

[Query about the blue sheets.]

  8 min.  Vendor Channel Protocol, Donald Eastlake
  ------------------------------------------------
(See slides)

Donald Eastlake (Huawei): ... Specifies an extension to the RBridge
  Channel facility so vendors can define their own messages between
  RBridges or between an RBridge and an end station on a link. ...

Sue: When you published the revived draft, please post to the list
  indicating the deployment scenario for this draft. This reminder
  will help people who are not hear to recall the deployments prior to
  the WG LC.

Donald: Sure. The only change from the old draft is to add the option
  of using a Company IDentifier instead of an OUI in case you are not
  a hardware Ethernet manufacturer and don't need MAC addresses.

 10 min.  Changes needed to ARP/ND Optimization, Li Yizhou
 ---------------------------------------------------------
             draft-ietf-trill-arp-optimization-08.txt
(See slides)

Yizhou Li (Huawei): ... [reviewed comments] ... The only real disagreement
  is that the review thinks that saying something (how to send keys to
  an RBridge so it could proxy for a target end station for SEND
  (Secure Neighbor Discovery)) is "out of scope" implies there is some
  way to do it. We think saying that doesn't imply anything either way
  as to whether it has been implemented. ...

Margaret: Try a wording change, like saying it is "unspecified" rather
  than "out of scope". Sometimes a little wording change like that can
  solve these things.

Sue: If you really get stuck on that point, maybe Alia can help.

Alia: The only real issue with this document is the Security
  Considerations.  That is what the DISCUSS is on. Of course we
  appreciate the other comments from reviews. But if a change is not
  DISCUSS worthy, it is ultimately safe to ignore it if it can't be
  resolved.

Yizhou: For the statistical counters and verification should be
  considered, we think it is up to the implementation.  We'll add more
  text.  .... Ops review suggests being above to configure some policy
  with YANG.

Sue: Due to the needed revision to the YANG model, we'll consider
  putting this in the YANG module.

Security section: ...

Sue: ... Alia could you help us out on what was in the ADs mind? ...

Donald: Yeah, in some of his comments he seemed to be asking for a
thorough threat analysis of Layer 2 security. I'm not sure that is in
scope for this draft...

Alia: I have not talked to the Security AD yet. I can do that if it
looks like it would be useful but I need more background first.

Yizhou: ...

  3 min.  TRILL and YANG - Sue Hares
  ----------------------------------
(See slide)

Sue: The YANG models that have not gone through the IESG are being
  requested to use the revised data store. ... Revised data store
  seems to be almost complete.  ... Options: (1) just publish existing
  YANG if deployed, (2) publish new YAMG conformant to the new data
  model, or (3) publish new YANG with existing YANG as an
  appendix. xxx

Sue: If no one has an opinion on which option, that's OK. We'll just
  do what's right.

Sue: Yizhou could you check if Huawei has implemented LIME?

Yizhou: I don't think so but I will check.

Sue: I think we have just enough time to talk about the smart end
  nodes draft.

  3 min   Smart End Notes
  -----------------------

Sue:  Please review this document in light of the very recent comment
  posted.

Fengwei: I will review.

Donald: I can provide additional points.

Donald: I commented on the smart-end-nodes and
  directory-assisted-encap drafts.

  1 min.  Wrap-Up, Chairs
  -----------------------

Sue: Go back to document status. ... Looks like we have covered
  things. My focus is to get these drafts through. I intended to Last
  Call all of these very soon except dci and OAM drafts. Any problem
  with that?

Donald: There may be some outstanding unresolved comments on the MPLS
  draft.

Sue: OK. But I will be pushing things through. This is a different
  season. Did I miss anything Alia?

Alia: The fast people respond to reviews, the fast the documents will
go through.

Donald: See you on the list and in Singapore.