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

Intarea Status Pages

Internet Area Working Group (Active WG)
Int Area: Éric Vyncke, Suresh Krishnan | 2010-Mar-23 —  

IETF-105 intarea minutes

Session 2019-07-23 1520-1650: Duluth - Audio stream - intarea chatroom


minutes-105-intarea-01 minutes

          IntArea WG Agenda
          IETF 105 - Montreal
          15:20-16:50        Tuesday, July 23rd, Afternoon Session II, Duluth
          Juan Carlos Zuniga (SIGFOX)
          Wassim Haddad (Ericsson)
          Note Taker: Tommy Pauly (Mirja Kühlewind as backup for first presentation)
          Discovering Provisioning Domain Names and Data, Tommy Pauly
          Proposed changes (https://github.com/IPv6-mPvD/mpvd-ietf-drafts/pull/11):
              - Association of DHCPv6 to RA-based PvDs (main discussion)
              - Removal of names and localized names from PvD additional info
              (group agreed)
              - Improved security considerations (group agreed)
          Lorenzo Colliti: moving the problem to when we need to select the PVD. In
          a DHCPv6 only network: RA without PIO (for default route) and DHCPv6 (for
          address(es)). If I can't select something that does give me connectivity
          that's not very useful.
          Ted Lemon: Stateless DHCP information should also be associated with
          all explicite PvD
          Erik Kline: Applications can mix and match information. PvD gives you
          explicit information
          Suresh: I try to understand what you mean by match the prefix. Let's go
          into specific DHCP-PD  option with a /48 and say matches a /64 PIO ? In
          my mind they do not match
          Lorenzo: what about a PIO with A=L=0 ? That can allow a configuration
          to have a PIO and be associated. (It is a NOP normally)
          Tommy: Please add comments to PR!
          Dave Thaler: About the registration of media type. The doc doesn't provide
          any argumentation for use of JSON. But contraint devices might not use
          that but cbor. The memo should include rationale for using only JSON.
          Tommy: Not clear if IoT devices would need that
          Paul Hoffman: Co-existence of things that does have an address
          assigned. If you have multiple PvDs you may have different resolvers
          with different views. Not clear which PVD to use.
          Tommy: Depends more on main PVD architecture. If you don't specify
          specific interfacee you get default resolver. If you select PVD, you
          get that resolver that is specified in there.
          Paul: Not clear in doc that applications need to be aware and what
          interactions there are.
          Erik: API requirements document
          Gorry Fairhurst: Back-off Timers MUST send at a certain time or do you
          mean delayed by a certain time?
          Tommy: Yes that might not be possible.
          Juan Carlos: Have you addressed all the comments from the SecDir?
          Tommy: Yes, we believe so
          IPv6 Support for Segment Routing: SRv6+, Ron Bonica
          MPLS and IPv6 flavors for segment routing; this is a proposal for another
          IPv6 approach.
          Will be shown in SPRING, this is an intro.
          Wanting to encode path state in each packet; programmable SR paths;
          leverage existing IPv6 features; minimize overhead.
          Strictly-routed and loosely-routed segment types exist
          Per-segment (send a packet to a policy enforcer) and per-path service
          SRv6+ defines a new routing header "compressed routing header". Encodes
          segment identifiers, to translate into addresses.
          Very small routing header!
          Also defines new options for per segment and per service instructions
          Several drafts (listed in slides) requested to read. Main one to read
          is draft-bonica-spring-srv6-plus
          David Marbell: Do you see this as an evolution of SRV6?
          Ron: Not sure yet; can coexist, can evolve. Will work out in SPRING.
          Erik Kline: Is there a SID distribution protocol?
          Ron: Yes! There are two :) ISIS and OSPF
          SOCKS Protocol Version 6, Vladimir Olteanu
          Covering changes in version -07.
          Aligned fields are hard in SOCKS due to hostnames. Now has all aligned
          fields, with padding to fill out domain names that don't align.
          Refactored options encoding
          Added options to have the proxy resolve addresses on behalf of the
          client. Imitates gethostbyname/getaddrinfo.
          One use case for proxied resolution is UDP; UDP proxied packets require
          the remote endpoint, and the address is smaller than the hostname in
          some cases.
          Ben Schwartz: Many applications need more than just the address records,
          such as ESNI. This is often not compatible with proxy protocols.
          Vladimir: Let's talk about that, yes.
          Suresh: It would be good to present this work to transport area as well.
          Gorry: As TSVWG chair, we have noted this draft in previous meetings. We'd
          be happy to get slides to the group.
          Tommy: +1 to Ben's point, we want to be able to get ESNI through; but
          also if we are just asking for A and AAAA, we don't necessarily want to
          block. See happy eyeballs v2 RFC.
          Vladimir: Focused on something that is simple and addresses needs of
          TOR group. But can also look at other use cases.
          Tommy: UDP proxying efficiency doesn't really need to do DNS resolution
          to the client just to get a short identifier (like and address). You
          could also just define a mapping of "long host name" to a constant-length
          Guidelines and Registration Procedures for Interface Types and Tunnel,
          Dave Thaler
          Issue raised, to clarify that various forms are not a new registry,
          but just alternate formats. New section added to discuss this.
          Recommends to IANA about how to clarify this in the website in a
          conceptual fashion.
          Also clarified ifType vs tunnelType; added Tunnel Types to the main
          Updated registration template for tunnel types
          Trying to figure out principle of when you define a new type (alternate
          values) versus reuse a generic one.
          The principle is that cases like UDP generic values have specific
          implications on multicast that don't apply to many other UDP tunnel
          Suresh: This is really good! I raised the issue for UDP for softwire,
          and it's good that this is clarified.
          Dave: We believe all issues have been addressed. Please raise new ones
          if you think there are issues.
          Suresh: I plan to send this to IETF last call right after this week.
          Gorry: Do we want transport area specific review?
          Dave: Don't think so. We may want some OPS area input re: the yang module
          and MIB module, seeing if this sets a precedent.
          Dan Romascanu (jabber): Reviews from the TSV Area and OPS-DIR would be
          Michelle Cotton: Re looking into tools, not sure how long that is going
          to take. If this document gets approved, it will still be sitting for a
          while potentially. The publication of the document may not need to wait
          on the tooling, so you may want a blurb for that.

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