Trill Status PagesTransparent Interconnection of Lots of Links (Active WG)
Rtg Area: Alvaro Retana, Alia Atlas, Deborah Brungard | 2005-Jun-29 —Chairs:
IETF-99 trill minutes
Session 2017-07-21 1150-1320: Karlin III - Audio stream - trill chatroom
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.