Wednesday 6 November 2024
Room: Wicklow Hall 2B
9:30-11:30, Local
Log into the IETF datatracker to access:
Rechartering: Chairs have already provided the updated Charter to the
IESG (Responsible AD: Jim Guichard).
WG engagement: The WG should be interested in the content and involved
in developing the document.
Please read documents and make comments.
Darren Dukes: I like this. I think that it is going to make my network
(social network and the network I am working on in my day job). So keep
it up.
Jim Guichard: As an AD, I fully support this approach. The more being
worked in the WG and the better quality of the documents would be.
Rakesh Gandhi: Give an example of how IPPM WG works. IPPM WG
automatically puts every WG draft in the agenda and gives 5 mins each.
In each session they are expected to provide an update.
Alvaro Retana: We ask the authors to provide updates before each
meeting. We keep monitoring the updates of the drafts status in an
Google Sheets. But the drafts don't have to be in the Agenda.
There are some documents with no update. It would be nice to at least
have an update.
Jim Guichard: This will help me to move the doc a lot quicker when I
understand about the history and progress of the doc. If there is no
update for one or two cycles, that would raise a red flag for us to have
a close look into its reasons. I do encourage people to give updates, so
we can move things through quicker.
draft-ietf-spring-srv6-security
Presenter: Nick Buraglio
Suresh Krishnan: RFC9602 should get added which is the main purpose of
the prefix. I will send a PR. The wording should be careful but should
be there. You need to figure out how it interacts with the other things
you are talking about.
Alvaro Retana: Please reflect any discussions on the github on the
mailing list since not everyone is following the repository.
Dhruv Dhody: +1 please include. We cannot ignore and should be explicit
about the interactions between the 5f prefix and the operators' own
prefix. To the Chairs, shall we have an early secdir review especially
on the threat model and terminologies.
Alvaro: How early do we want it? We will have one before or around the
WG last call.
Dhruv Dhody: I am worried about the terms we are using here, like "on
path" and "off path". We need to, at a very high level, make sure of
getting the framework right rather than focusing on the content.
Nick Buraglio: We discussed a lot about the models we used and would
like to see more feedback.
Alvaro Retana: We can request a review in the security directorate and
target on that part of the document. Any extra reviewers?
Two volunteers in the room.
Boris Khasanov: I will review.
Presenter: Zafar Ali
draft-ietf-spring-cs-sr-policy
The authors would like to request WGLC.
Please review and provide feedbacks.
Alvaro Retana: We look for engagement and a Shepherd. Please contact us
if you want to volunteer.
Presenter: Weiqiang Cheng
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
The authors would like to request WGLC.
Alvaro Retana: How many of us have read this draft? This has been
checked in the DHC WG. Please review from the aspect of the SPRING WG.
A few volunteers in the room to review.
Presenter: Jiaming Ye
draft-lin-spring-srv6-aware-context-indicator
Jim Guichard: In the SRv6OPS session，it shows some renewed interests in
the service programming. Please review the service programming document
and provide feedbacks on the mailing list. There are some dependancies.
Daniel Bernier: Have you investigated the complexity for making those
mappings towards Context-ID? How will those impact performance?
Jiaming Ye: More discussions in the mailing list.
Presenter: Guozhen Dong
draft-dong-spring-sr-4map6-segments
no comments
Presenter: Liyan Gong
draft-cheng-spring-srv6-encoding-network-sliceid
no comments
Presenter: Liyan Gong
draft-gong-spring-lldp-srv6-extensions
Daniel Bernier: We have similar implementations. If you are trying to
redistribute your LLP into IGP, why do you need to carry the TLVs, you
can just do the TLV adaptation when you do the redistribution? We can
discuss more in the mailing list.
Liyan Gong: Between the host and the access, there is no IGP deployed.
Dynamic protocol is much more complicated for the host. That is why we
use LLP.
Aijun Wang: There is already a draft on using DHCP to distribute the
locators. Why LLDP again? What are the advantages?
Liyan Gong: LLDP is widely deployed in a DC network but DHCP is not.
Weiqiang Cheng: For different scenarios, especially when there is no
DHCP.
Aijun Wang: To me, DHCP is more popular. If you want to push forwards,
you need to compare the existing solution and which scenarios your
proposal can be used.
Liyan Gong: I will elaborate more on the scenarios.
Sasha Vainshtein: LLDP is not an IETF protocol, it is IEEE protocol. It
is owned by another SDO. Not sure about the procedure and how we can
handle this protocol.
Acee Lindern: IEEE already has the OUI for IETF to put information for
the LLDP. So we can extend it and that is fine. We have a BGP discovery
draft that does something simpler for BGP peer discovery.
Alvaro Retana: The LSVR WG has been working on the discovery as well
with LLDP. IEEE has extended LLDP to version 2. So there is a way to do
if we want to do. But we need to figure out first this is something we
want to do.
Acee Lindern: Why does not the base IPv6 neighbor discovery just work
for the address itself and locator?
Liyan Gong: We have also considered and compared the neighbor discovery
protocol. LLDP is simpler and more fundamental than ND in our opinion.
These are two protocols for different scenarios, and we can choose which
one to use.
Sasha Vainshtein: Why not advertise necessary information in RA which is
part of NDP and an IETF protocol?
Liyan Gong: Please let's discuss on the mailing list.
Jeff Tantsura: Just to emphasize what Sasha said. The host is probably
already using SLACK or DHCPv6 to get the address. It is extendable and
we know how to use it. Much better than do anything like this.
Alvaro Retana: More discussions on the mailing list. It is good that we
see a lot of engagements.
Presenter: Yuta Fukagawa
draft-watal-spring-srv6-sfc-sr-aware-functions
Greg Mirsky: How the active SRv6 OAM will behave in this environment? Do
you envision that service functions will be required to handle SRv6 OAM?
Yuta Fukagawa: In the last IETF Hackathon, we use some OAM for SRv6.
Greg Mirsky: I can point you to the documents on SFC NSH OAM. The common
problem is that SFs are not expected to handle transport or underlay OAM
but at the same time they need to traverse the same sequence of SF
Forwarders.
Aijun Wang: BGP-LS and PCEP are used for the NBI. The PCEP can already
accomplish all your functions. PCEP Flowspec has been published as RFC.
For topology info collection there is PCEP-LS. Would you like to unify
and simplify the northbound protocol using PCEP?
Yuta Fukagawa: Not familiar with PCEP, will check later.
Zafar Ali: I have a draft on service programming OAM in SPRING. Happy to
work on the OAM part with you.
Daniel Bernier: Will you use BGP-LS extensions to configure functions?
There are a lot of attributes. We have trouble using NSH. Now we are
using BGP-LS. It is good to discover a function in the network to be
part of the overall forwarding domain but there are things that do not
fit in the model.
Yuta Fukagawa: There are customer-specific functions. We want to use
BGP-LS to configure.
Ketan Talaulikar: Co-author of the BGP-LS draft. We have similar
feedback from a lot of operators. You should already have network
orchestration functions that can easily feedback. BGP-LS is an option.
It is easier to do it out of the network protocols via the orchestration
mechanism directly. Happy to discuss further offline.
Yuta Fukagawa: We like to use BGP-LS because of its extensions.