* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Trill Status Pages

Transparent Interconnection of Lots of Links (Active WG)
Rtg Area: Alvaro Retana, Alia Atlas, Deborah Brungard | 2005-Jun-29 —  

IETF-99 trill minutes

Session 2017-07-21 1150-1320: Karlin III - Audio stream - trill chatroom


minutes-99-trill-00 minutes

          Hilton Prague, Prague, Czech Republic
                  Friday, 21 July
                  11:50-13:20 Karlin III Room
          Chairs:    Sue Hares
          (Hickory Hill Consulting)
                     Jon Hudson (self)
          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
            5 min.  Status, Chairs
          See Slides.
          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.
          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
          I can get the draft through IETF Last call and on the IESG
          faster. If you are no responsive, well, it can take a lot
          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
            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
          [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]
          [zero IP header checksum] [congestion control] We have this
            problem in
          the IETF that when we have a tunnel, and TRILL over IP is
          a tunnel, it is hard to tell if the traffic being carried
          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?
          Does anyone have any comments on this?
          Ramkumar: For the case where you
          are just working with the control
            plane, does this impact it?
          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
          that TRILL (like other protocols) might need this
          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. ...
          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.
          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.
          Margaret please ask on the list regarding TRILL deployments about
          NAT usage. ...
          Margaret: The NAT is the largest potential addition to
            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
            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
          (See slides)
          Yizhou Li
          (Huawei): ... [reviewed comments] ... The only real disagreement
          that the review thinks that saying something (how to send keys to
          RBridge so it could proxy for a target end station for SEND
          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
          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
           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.
          Due to the needed revision to the YANG model, we'll consider
          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...
          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
            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
          or (3) publish new YANG with existing YANG as an
            appendix. xxx
          If no one has an opinion on which option, that's OK. We'll just
          what's right.
          Sue: Yizhou could you check if Huawei has implemented
          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.
          min   Smart End Notes
          Sue:  Please review
          this document in light of the very recent comment
          I will review.
          Donald: I can provide additional points.
          I commented on the smart-end-nodes and
            1 min.  Wrap-Up, Chairs
          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
          Sue: OK. But I will be pushing things through. This is a
            season. Did I miss anything Alia?
          Alia: The fast people
          respond to reviews, the fast the documents will
          go through.
          See you on the list and in Singapore.

Generated from PyHt script /wg/trill/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -