Wednesday 24 July 2025
17:00 - 19:00, Local
Room: Castilla
Log into the IETF datatracker to access:
RFC9800 is published.
Two interims are being considered. One on Security and one on the SR and
NRP topics.
Presenter: Nick Buraglio
draft-ietf-spring-srv6-security
Alvaro Retana: Secion 6.3, it is better to clarify the scope of control
plane and the management plane.
Dhruv Dhody: PCECC is good to be added. Basic PCE and BGP where we talk
to headend, needs to be captured as well. Then ask other WGs to review
to make sure everything is consistent.
Alvaro Retana: We are going to discuss in the interim meeting. Volunteer
to be a shepherd - Zafar Ali.
[From Chatbox
Presenter: Rakesh Gandhi
draft-ietf-spring-stamp-srpm
Diego Achaval: Split the draft, one for MPLS and one for SRv6.
Maria Matejka: Better to have a separate session on what are being
measured.
Rakesh: Will add a session on what are the metrics.
Himanshu Shah: Can the native SR-MPLS be used only not dependent on MNA?
Rakesh: In this particular mode, one way to do it is MNA. There might be
other ways. MNA is the work MPLS WG is working on.
Alvaro Retana: To Himanshu, is it ok for you to split the draft?
Himanshu: I would like not to support MNA.
Rakesh: MNA allows network programming, and it is only used by the
endpoint on the reflector only, not any midpoint nodes.
Himanshu: Then we can also do it with SR-MPLS. Your slides show that the
packet is punted to the control plane, right? I suppose you can use the
binding SID with SR-MPLS.
Rakesh: You can do it just you dont get the T2.
Joel: We should consult with MPLS WG on whether we should use MNA or
not. The SPRING WG should not choose.
Rakesh: One way to do it is to split the document and work on the
SR-MPLS part.
Boris Khasanov: Implementation should include the open source stamp
client.
Rakesh: We will add it.
Zafar Ali: Support to split the draft.
Weiqiang Cheng: Support to split the draft. SRv6 part is mature and
should go first.
Bruno Decarene: I suppose that you are defining two code points, one for
MPLS and one for SRv6. But in IANA session, there is nothing.
Rakesh: We use the code points from vendor specific which is not
advertised into IGP, if there is an interest, standard code point can
also be defined. It is an informational draft. If we request code
points, it may become standards track.
Bruno Decarene: For SRv6 it is first come first serve. We can get one.
Not sure about MNA.
Rakesh: Another reason to split the draft. Will add a section for the
SRv6 endpoint first come first serve.
Bruno Decarene: Some sections are data plane specific and some are
agnostic to data plane. What is your plan in splitting the draft?
Rakesh: The measurement mode will be repeated. The encodings is data
plane dependent. Will make sure the consistency between the two
document.
Alvaro: You can also reference the definitions from one to the other.
Rakesh: If SRv6 draft is done, the SR-MPLS one can refer to it. Then we
dont need to duplicate all the text.
Alvaro: There is interest in the room on splitting the draft; we will
confirm on the list and consult with MPLS.
Presenter: Kamran Raza
draft-ietf-spring-srv6-yang
Jeff Tantsura: The RFC9800 has been published. Please align the name
conventions.
Dhruv Dhody: The compression should be in the base or as an optional.
Please consider.
Alvaro Retana: A PCE draft depends on this.
Dhruv Dhody: Yes, we need the SRv6-types.
Alvaro Retana: No support or opposition for splitting this draft, so we
take to the list.
Presenter: Kamran Raza
draft-ietf-spring-sr-policy-yang
Dhruv Dhody: Slide 8, only for device model? or sr policy controller as
well?
Kamran Raza: For Both.
Dhruv Dhody: Let's put the key as headend.
Himanshu Shah: Another flag on the eligibility to come. Please consider
to add.
Boris Khasanov: Should we stop and wait while other drafts which want to
modify SR Policy will be proceeded in the WG? How should we proceed?
Alvaro Retana: Dependency among drafts. Please discuss on the mailing
list. We need thorough review, and please engage to make sure all the
features are included.
Presenter: Zafar Ali
draft-ali-spring-srv6-policy-sid-list-optimization
Greg Mirsky: If the encapsulation/SID list is different for the data
packets and active OAM, how to make sure the OAM packets will receive
the same treatment and follow the same path to receive useful
observation information.
Zafar Ali: The data traffic will always follow the same route.
Greg Mirsky: When you expand OAM, it is maintenance. It is deemed for
configuation.
Zafar Ali: We can make changes.
Boris Khasanov: Please add an implementation session.
Zafar Ali: Will add.
Dhruv Dhody: I dont agree with the way the document list procedures in
PCEP and then list BGP. Should focus on the information in general and
not the protocol procedures of other WGs.
Zafar Ali: We will address.
Rakesh Gandhi: To Greg, either to monitor service or sr policy, it will
follow the same path.
Zafar Ali: Traffic will take the same route because of the same locator.
Rakesh Gandhi: The idea for PM is whatever you are monitoring it carries
the same encapsulation.
Bruno Decraene: How to keep consistent with YANG? You need a flag also
in the YANG model?
Zafar Ali: We are open either way the Chairs like to guide us.
Presenter: Amal Karboubi
draft-karboubi-spring-sr-policy-eligibility
Boris Khasanov: If multiple CPs are eligible, please consider the impact
which it may bring for the router's control plane. Because it looks like
addtional criteria which should be tracked by device control plane.
Amal Karboubi: Just one more addtional property.
Himanshu Shah: It has nothing to do with the preference of which one you
are going to select. It is just a matter of checking whether it can
carry the traffic because it is meeting your intent whatever it is. Take
a poll on making progress?
Alvaro: How many have read the draft?
[Hands up: about 10%.]
Andrew Stone: To Boris's concern, you could still be running BFD even
without this. The eligibility in this draft is another criteria in that
active factor.
Ketan Talaulikar: In the RFC9256, it says there is only one active CP
and is programmed in the forwarding plane. Need not to be use case
specific.
Rakesh Gandhi: The CP is active in the control plane and you are doing
the measurement, it doesnot have to be in the data plane.
Boris Khasanov: If you insist that it's needed please test it and
explicitly mention about how many CPs with eligibility can be supported
by the particular device in the product documentation.
Alvaro: Every draft should include the operational considerations to be
published as RFC, just like security considerations.
Presenter: Feng Yang
draft-yang-spring-sid-as-source-address
Sasha Vainshtein: Slide 5, it assumes that each VPN instantiation in
each PE advertise exactly one VPN SID. But this is not mandatory. One
VRF can advertise multiple SIDs. Which VPN should use the source IP?
Feng Yang: If traffic is sent out from VPN A, then it should use the VPN
SID of VPN A.
Alvaro: Take to the mailing list.
Tom Hill: Not sure this is secure and should be allowed. Place the SID
in the SA then call it source routing which seems wrong. SR is intended
to be run inside a trusted domain.
Feng Yang: Security issues have been identified in the security draft.
Tom Hill: These problems were not intended to be solved with what is
effectively source-spoofing. We should build our networks carefully,
with the security considerations in mind.
Dan Voyer: Agree with Tom. Misconfiguration cannot be qualified as
attack. We like to keep things simple. If it is not mentioned in the
draft, the assumpation should be that it is a single control domain.
Weiqiang Cheng: This solution is to solve a deployment problem. Firewall
will filter some packets against their source address by mistake.
Kamran Raza: Slide 6, if VPN has more than one SID, how does PE1 decides
which address to use as a source address? If you can use any of them
then the egress PE maintaining the source verification table will have
the scale challenges.
Feng Yang: RT will determine what to use.
[From Chatbox
Presenter: Feng Yang
draft-yang-spring-srv6-verification
No questions.
Presenter: Andrew Stone
draft-stone-spring-mpte-sr
Zafar Ali: There are also other APIs building such trees in the network.
DAG ID is application aspect. Color is intent. I am against using
anything for color. DAG is a construct that can map to binding SID and
the mapping is local to application.
Andrew Stone: Are you recommending to plug something else into color?
Zafar Ali: Color is the intent. The reason why you compute the policy is
encoded into the color. You can reuse the color.
Andrew Stone: Color is used for headend steering. I dont want to use
color,
Himanshu Shah: This is for certain topologies.
Andrew Stone: It does not work for a ring topology. It will be use case
dependent and topology dependent.
Kireeti Kompella: Slide 4, weight zero is what you want to standardized?
Andrew Stone: Yes, weight zero is useful but missing.
Nitsan Dolev Elfassy: Compared to Kireeti's proposal in TEAS, which is
better?
Andrew Stone: Here the data plane is segment routing. Here is a more
controller oriented solution. The end result you will still get a DAG.