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
-
Agenda Bashing, WG & Document Status Updates (Chairs)
5 mins
- No comments/bashing on the agenda
-
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.
-
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.
-
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.
-
SCION Control Plane - Nicola Rustignoli
draft-dekater-scion-controlplane-00
15 mins
-
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.
-
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.