Minutes IETF117: intarea: Tue 22:00
minutes-117-intarea-202307252200-00

IntArea WG Agenda

IETF 117 - Hybrid meeting, San Francisco (USA) + Online
Tuesday, July 25, 2023

15:00-16:30 Tuesday Afternoon Session III (Pacific Standard Time, UTC-7)

Chairs:
Juan Carlos Zuniga (Cisco)
Wassim Haddad (Ericsson)

Minute Taker: Luigi Iannone

1. Agenda Bashing, WG & Document Status Updates (Chairs)
   5 mins

   • No comments/bashing on the agenda

2. IANA Considerations and IETF Protocol and Documentation Usage for
   IEEE 802 Parameters, Donald Eastlake / Juan Carlos Zuniga / Glenn
   Parsons
   draft-ietf-intarea-rfc7042bis-06
   20 mins

   • Summary IEEE statement about rfc7042bis by Glenn Parsons.
     Few comments mainly editorial and some technical about Ethernet
     addresses (but they are nits mainly).

   • Donald Eastlake: submitted today -06 taking care of IANA
     considerations. Will submit another revision taking care about
     IEEE comments by the end of the week.

3. IP Addressing with References (IPREF), Waldemar Augustyn
   draft-augustyn-intarea-ipref-01
   15 mins

   • Update provided on the latest revision -01.
   • Éric Vyncke: Please recall and describe the main idea.
   • Waldemar Augustyn provided short description.
   • JC Zuniga: On the chat there are comments about
     clarification needed on the problem statement.
   • Waldemar Augustyn: The problem is that there are two
     Internets (v4 and v6), this solution will create one single
     Internet.

4. Communicating Proxy Configurations in Provisioning Domains - Tommy
   Pauly
   draft-pauly-intarea-proxy-config-pvd-00
   15 mins

   • Draft presentation.
   • Lorenzo Colitti: We should avoid using PAC. What to do with
     people using PAC files?
   • Tommy Pauly: Better to start with something simple but it
     fits you may want to remove PAC files.
   • Ben Schwartz: Need to better define DNS zone. Not sure if
     INTAREA is the best place depends on the use of PAC.
   • Tommy Pauly: yes, and there are other things we may want to
     put in.
   • Éric Vyncke: INTAREA is the most suitable place except if we
     extend the work.
   • Tobias Fiebing: An important point is to consider as well
     HTTPS and the use of TLS.
   • Tommy Pauly: Good point PAC files are never protected with
     TLS.
   • Tommy Pauly: We will continue the discussion and ask for
     adoption.
   • JC Zuniga: Since it is -00 it is a bit too early but
     continue the discussion.

5. SCION Control Plane - Nicola Rustignoli
   draft-dekater-scion-controlplane-00
   15 mins

• Skipped

1. Trusted Domain SRv6 - Andrew Alston
   draft-raviolli-intarea-trusted-domain-srv6-01
   15 mins

   • Draft presentation.
   • Tom Herbert: Where is this ethertype? In the ethernet frame?
   • Andrew Alston: Yes, we are proposing a new ehtertype
     explicitly identifying SRv6.
   • Tom Herbert: This is like saying SRv6 is not IPv6. You are
     redefining IPv6.
   • Andrew Alston: Yes, but it is an option. Either you run SRv6
     as IPv6 or separately.
   • Tom Herbert: Is it feasible to deploy it worldwide? We are
     munging layers, running SRv6 as a pseudo protocol, which is
     still IPv6. Why not filtering based on the presence of the
     routing header at the edge of the network?
   • Andrew Alston: There are cases where you do not need SRH to
     run SRv6. This means that filtering only on SRH may not work. We
     found several cases like this, and we were left only with
     longest-Prefix Match (LPM) filtering. Deploying it is not more
     difficult than deploying MPLS. This is an operator choice.
   • Tom Herbert: Is also about management. It looks pretty
     invasive. Filtering at the edge separates the issue.
   • Andrew Alston: Yes, but often there is no clearly defined
     edge.
   • Tom Herbert: If there is no edge and the new ethertype is
     used what prevents leaks to device not supporting it?
   • Andrew Alston: I enable this ethertype only where is needed.
   • Tom Herbert: But what if other side will not process it
     because it is not enabled. I do not see the point of having
     another ethertype for the same protocol.
   • Thanji Jiang: Form a technical viewpoint, if you define this
     ethertype you can then ask ethertype for a lot of other
     tunneling protocols. Further, as an operator, in our large
     network SRv6 is already deployed deploying this new solution
     will be costly to deploy.
   • Andrew Alston: On the first question, did we not violate the
     layering when creating SRv6? For the second question: this is
     optional, nobody must reconfigure his network if does not want
     to.
   • Thanji Jiang: The IETF has already solutions to handle the
     issue. You are creating something to handle for something that
     does not need to be handled.
   • Toni Li: Compared to the rest of the code to build SRv6, the
     ethertype is noise.
   • Ron Bonica: The base srv6 draft the SRH draft and its
     security consideration section talks about the security issues
     and that it must be run in a limited domain. This is sometimes
     very difficult especially when there's no SRH in the packet. The
     amount of effort that's required to implement this option is
     really pretty nil pretty slim and I can't see why anyone would
     object to it.
   • Tony Przygienda: It is easy to add this kind of ethertype
     and filter on them. I do not understand the objections. Without
     this you will have zillions of entries in your TCAM. With this,
     you choose where to enable it and have an easy way to filter.
   • Dan Voyer: The document is based on the perception that
     operators have a hard time to run their network. I'm not against
     the option although there's a bunch of downsides to it. Maybe we
     should not tell operators how to run their network or say it is
     easy to deploy. In very large networks, reconfiguring everything
     will be a problem.
   • Andrew Alston: Apologies if it came across that way. Errors
     around LPM filtering happens for multiple reasons. This option
     is designed to avoid mistake that happen in large networks.
   • Dan Voyer: This is not the only solution.
   • Andrew Alston: I am not saying is the only solution, but I
     do not see another solution.
   • Dan Voyer: It is not a scalability issue, it is also a
     management issue.
   • Andrew Alston: Yes, we are not imposing a solution, we are
     proposing another choice. This is completely optional.
   • *Eric Kline: There is a draft in 6MAN for a dedicated prefix
     for SRv6, please read it.
   • Andrew Alston: This draft is complementary.
   • Eric Kline: Yes, no conflict.
   • Darren Dukes: The match that we defined in RFC 8754 as a LPM
     match is for the single LPM. What you are talking about is for
     the single prefix from which we are allocating SRv6 SIDs, is
     that correct?
   • Andrew Alston: Yes.
   • Darren Dukes: Which turns in one single TCAM entry, right?
   • Andrew Alston: Depends on the hardware. Per port or per VLAN
     ACL will end up using a lot of TCAM entries.
   • Tom Hill: Co-author of this draft. Distinguish between IPv6
     and SRv6 they are not the same and they do not do the same job.
     If I have an SRv6 signal transport Network and I have a customer
     who is also receiving IPv6 Transit from me if they enable SRv6
     how do I filter their packets if they make a mistake, and they
     start sending me SRv6? Not sure it's possible with ACL, because
     they could use their RIPE or ARIN allocated IPv6 addresses as
     SIDS without an SRH and leak it.
   • Andrew Alston: If you find the answer let me know.
   • Tony Przygienda: We did not partition the IPv6 so far. If we
     change the semantic of a v6 prefix deployed device will be
     non-compliant. Device will forward SRv6 prefix by default while
     with an ethertype the traffic will be dropped by default is not
     supported or not enabled.
   • Lorenzo Colitti: If you allocate a different ethertype we
     are forking SRv6 from IPv6 and they can evolve completely
     differently. This should be considered.
   • Andrew Alston: SRv6 is not IPv6. Potentially we are forking
     the protocol that is why I brought it here. SPRING is not
     chartered to work on a new data plane. If have an ehtertype this
     is not completely IPv6 so we cannot go to 6MAN. More discussion
     is appreciated, may be adoption if evolving in this WG or
     suggest where to go.

2. Civic Location and Geospatial Coordinate Support in IPv6 ND - Sri
   Gundavelli
   Draft-gundavelli-6man-nd-location-00
   5 mins

   • Draft Presentation.
   • Benjamin Schwartz: This option is defined for DHCP v4 and v6
     why it is not sufficient?
   • Sri Gundavelli: In RFC 6106 we defined the DNS configuration
     option, if with the RA you can deliver additional parameters
     including the location you deliver the whole configuration.
   • Benjamin Schwartz: Configuration in IPv6 can be done with
     and without DHCP, but it does not mean that what you can do with
     DHCP has to be done as well without. You mentioned a few reasons
     why DHCP is a good place for this metadata for the specific
     host. RA is not a good place.
   • Sri Gundavelli: We have already RFC 6106 and RFC 8801are
     already standardized configuration options delivery to
     end-points. This allows you to do the same but without DHCP.
   • Lorenzo Colitti: You need to think about what is your update
     strategy. With DHCP you cannot update. With RAs you can update,
     but the update applies to everyone. What is your update
     strategy? Because location is per client and per point in time.
     Do not propose RA unicast. RA are used for bootstrapping and
     everything should come in one packet. So PVD is the best option
     here, because they have an update strategy.

   • Éric Vyncke: Those PVD can be created dynamically per host.

     • Jen Linkova: Support Lorenzo's point. What happens if
       you receive different RAs, like in a multi-homing
       environment?

   • Sri Gundavelli: We need to characterize the environment. For
     instance, in WiFi, you do not send broadcast RS and wake up
     everyone. If you want to deliver a client specific prefix you
     can do a unicast RS and unicast RA, which are not necessarily
     bad.

   • Q Miseli: This does not belong in RAs. This will become a
     mess. Also send massive packets to everyone is not a good idea.
     DHCPv6 is an option and PVD seems like a better option.
   • Tanji Jiang: You showed a slide about 5G, but 5G already
     defined some good technology for the positioning part. The same
     done on the IP layer will be worse than the 5G radio.
   • Benjamin Schwartz: Coming back to Lorenzo's point. You can
     re-run DHCP if client wants new fresh information. If you want
     to use PVD I suggest you use static PVD, not dynamically
     generated PVDs, hence move the geolocation service somewhere
     else.