SPRING @IETF-122

Wednesday 19 March 2025
Room: Chitlada 3
9:30-11:30, Local

Chairs: Alvaro Retana, Bruno Decraene, Joel M. Halpern
Secretary & Minutes Taker: Shuping Peng

Log into the IETF datatracker to access:

• MeetEcho
• Notes
• Zulip

SPRING WG Meeting Agenda

SPRING Status - Chairs

No comments

SRv6 Security Considerations

Presenter: Tal Mizrahi
draft-ietf-spring-srv6-security

Milestones for the next steps are presented.

Tom Hill: In 7.1.3 Address Range Filtering, the updated text, "Some
examples of an infrastructure address range for SIDs are: 1. ULA
addresses 2. The prefix defined in [RFC9602]. 3. GUA addresses", is
this intended to be an ordered list of preference?

Tal Mizrahi: It is not the text I wrote. Please take to the mailing
list.

Dhruv Dhody: Where is the place for NMS there? I assume when hear
control plane, what it means a distributed control plane. Can PCE be
included in that picture?

Tal Mizrahi: Yes, thank you.

Alvaro Retana: This work is asked by IESG, that is why we put the
milestones to make it progress faster. We will have an interim, maybe in
May. Please read the document. We need WG engagement and interactions.
Please reflect all the discussions in the mailing list where the WG
works. They should be public discussions. Please make sure everyone
knows what is happening.

Eligibility Concept in Segment Routing Policies

Presenter: Himanshu Shah
draft-karboubi-spring-sr-policy-eligibility

Zafar Ali: Two different ways of doing this eligibility check, one is
local and one is PCE. There are some drafts in this WG on the local way.
You bring the PCE way in this draft. What is the local versus remote
interaction? What is the interaction? Two entities are taking the same
action. Please clarify.

Himanshu Shah: You mean that multiple actors setting/resetting and
modifying eligibility flag, and then how you coordinate those things. We
need to work out the details. Who set it? How to synchronize? The
orginal purpose of this draft is that there is this additional
eligibility check.

Zafar Ali: Two drafts talk about two types: local eligibility check in
local box and NMS-based action on CP in IDR WG.

Himanshu Shah: YANG, BGP, PCE, Controller, CLI, all those things need to
be added. The purpose of this work is to make sure that additional check
through the elgibility attribute is needed and make it in place. Based
on the WG feedback, this is generic enough and can be applied to many
other use cases. This is the starting point. All the additional details
need to be added.

Alvaro Retana: Please take to the mailing list.

Boris Khasanov: Where is the mentioned compressed SID list? (Himanshu
Shah: in the next draft). Specific clarification for your case is needed
to differentiate with SRH compression. This eligibility concept brings
significant changes to RFC9256 for active CP choosing process. Question
to Chairs: RFC9256bis?

• [From Chatbox] Ketan Talaulikar: Eligibility does not change
  validity. It is an additional thing. So, it perhaps updates rfc9256
  but not a bis ... It is not a bugfix on 9256. Or at least that is
  how I see it

Himanshu Shah: This is an important concept additional to the regular
check. Should these be a RFC9256bis? We are open and leave it to Chairs.

Boris Khasanov: We need consistency with RFC9256 because CS SR policy is
a subset of SR Policy. Later we may have another SR Policy application
which will bring also new concept etc. That is why a consistency is
important.

Alvaro Retana: Consistency is important. We can discuss on the mailing
list.

Aijun Wang: In case of a link failure, the headend of the path will
calculate the path. Why not remove the original path using the newly
defined flag?

Himanshu Shah: Not sure about the question. Please send to the mailing
list.

Alvaro Retana: Please look at the chats and drafts in IDR, and take to
the mailing list.

Himanshu Shah: There are multiple drafts suggesting different ways to do
it.

Circuit Style Segment Routing Policies with Optimized SID List Depth

Presenter: Himanshu Shah
draft-karboubi-spring-sidlist-optimized-cs-sr

The work above (Eligibility concept) was suggested to be taken out from
this work because the concept is more generic.

Zafar Ali: I am a co-author of the cs-sr draft and I implemented this.
The reason we did not do it this way is that if we use Node SID not
adjacency SID, then FRR can kick in, so we use unprotected because we
want path protection to kick in not FRR. If you do it this way, you will
have two issues: one is that local will not detect failure, and the
other is that you put traffic on a detour path which is not booked. Then
you try to use PCE to solve this problem. This is architecturally
incorrect. Your assertion that binding SID is cumbersome is very
implementation specific.

Himanshu Shah: These have been discussed before. You have to inverse the
timers. We have implemented and deployed for a couple of operators. It
does work with compression and inverse timers for end-to-end protection
vs. local faults. This is no novelty in using adjacency SIDs for the
entire path. The thing is how to make it better.

Zafar Ali: This is not good that you slow down the whole IGP convergence
by going the link detection slower so your path protection can win. With
compression I have hardly seen anybody needing binding SID. Binding SID
may be cumbersome for you but not for us.

Alvaro Retana: Please continue the discussion in the mailing list.

Flexible Candidate Path Selection of SR Policy

Presenter: Yisong Liu
draft-liu-spring-sr-policy-flexible-path-selection

Himanshu Shah: This is an usecase. There are many usecases where you can
apply elgibility. Those use cases should not be defining different ways
on how can switch over from CP one to CP two. If the intent is not met
you invalidate the CP.

Alvaro Retana: Thank you for volunteering to working together with all
other authors on getting some consistency.

Ketan Talaulikar: In RFC9256, we have the tiebreaking rules which are
strictly governed by the operator that is provisioning the SR policies
via BGP, PCEP or CLI. They are static in nature. Then we have the
validation rules for the situations on whatever can be detected on
headend. We are adding more qualitative checks which change dynamically
based on network conditions. This is something additional. I like the
eligibility proposal. Whatever it is called is up to the WG. My
suggestion is to update RFC9256. I don't believe there is a need for a
bis. I will summarize on the mailing list.

Yisong Liu: Our proposal is on how to active the CP not how to select.

Boris Khasanov: Similarly to that Ketan said - we need to manage the
consistency with RFC 9256, if it says CP is active then 1 SL is active.
Here we also bring additional elegibility criteria vs. RFC 9256 as in
previous drafts.

Shraddha Hegde: Is the eligibility criteria or whatever validation used
only when PCE initially installs the paths and you select, or is the
router continously monitoring and evaluating the eligibility and
reselect if not eligible?

Yisong Liu: We can align with the eligibility draft. Yes, we are
continously monitoring.

• Chat logs on the eligibility related topics are list at the end of
  the note.

SR-MPLS Aggregation Segment

Presenter: Bruno Decraene
draft-decraene-spring-sr-mpls-aggregation-segment

Alvaro Retana: I locked the queue because we are running late.

Martin Horneffer: All PEs do the double push instead of single push?

Bruno Decraene: Yes.

Martin Horneffer: That means all the PEs in the network would need to do
this otherwise I cannot profit from the better scale in the P routers.

Bruno Decraene: Absolutely.

Martin Horneffer: Did you consider whether this would work with LDP
switching? If a PE does not know SR-MPLS but uses LDP, perhaps BR will
do the stitching, so the BR would do another push and get it all
together. Have you considered this yet?

Bruno Decraene: Not yet. We need to consider that.

SRv6 SFC Architecture with SR-aware Functions

Presenter: Wataru Mishima
draft-watal-spring-srv6-sfc-sr-aware-functions

Ketan Talaulikar: Coauthor of the BGP-LS draft (BGP-LS Advertisement of
Segment Routing Service Segments). It is good that we have done this in
Hackathon. Look forward to your inputs on our document and collaborate.

Advertise SRv6 Locator Information by IPv6 Neighbor Discovery

Presenter: Liyan Gong / Changwang Lin
[draft-gong-spring-nd-advertise-srv6-locator][10]

Cheng Li: What is your motivation? Why to extend this to the host? Any
security consideration of doing this?

Liyan Gong: The scenario is in the Data Center network. The host may be
a server. Very easy to program the host to the whole path with SRv6.

Tom Hill: Should consider the security impact. It should be within a
trust domain. The host is not traditionaly trusted to operators. Try to
refactor about what we are doing and why as well as the security impact.
This will be a particularly easy vector to inject something malicious
into your SR network.

Erik Kline: Security concern. What is the trust model? In the data
center there could be a trust model there. But in the scenario like a
host connecting to a CPE? I dont understand the trust model at all.
Please add the trust model in the security consideration section of the
draft. You will probably also have the MTU issues because LIO is going
to be big and exceeds MTU size.

Suresh Krishnan: Not sure this is the best way to do this draft. Please
check with the rtgwg and 6man wg since there are similar work there.
6man review is needed. Please do it sooner than later.

Alvaro Retana: Please discuss in the mailing list.

SRv6 Path Verification

Presenter: Feng Yang
draft-yang-spring-srv6-verification

Tal Mizrahi: HMAC is used to verify the SRH is not modified. What you
want to do is to verify a path which is different. Path verification is
similar to what we considered in IOAM Proof of Transit (PoT), the onion
ring approach. We did not pursue it because the complexity is
prohibitive. Worth looking back.

Feng Yang: Purpose is similar.

Alvaro Retana: This is the draft that has a very close relationship to
6man since you are proposing an enhancement to RFC8754. It is important
to look at it in a wider way.

Benchmarking Methodology for Segment Routing

Presenter: Paolo Volpato
draft-ietf-bmwg-sr-bench-meth

Alvaro Retana: Please have a look at this draft, make comments and
feedback.

Export of Path Segment Identifier Information in IPFIX

Presenter: Yao Liu
draft-liu-opsawg-ipfix-path-segment

Cheng Li: Useful. Support.

Alvaro Retana: Not a SPRING draft. Please review on the mailing list.

Alvaro Retana: We need WG engagement. Please read and review drafts,
make comments.

*** Chat logs on the eligibility related topics:

• Susan Hares: What is the precedence between IDR, PCE, netconf, and
  local setting of eligibility.
• Dhruv Dhody: Is eligibility limited to circuit style or the plan to
  make it generic?
• Changwang Lin: Set the forwarding status of the path or segment list
  to DOWN, allowing switchover to another path for forwarding.
• Changwang Lin: I think General is better, there might be other
  scenarios where this status needs to be set.
• Susan Hares: +1 to Dhurv's comment. If circuit style, then how do
  you make sure it does not interact with generic?
• Ketan Talaulikar: Eligibility does not change validity. It is an
  additional thing. So, it perhaps updates rfc9256 but not a bis ...
  It is not a bugfix on 9256. Or at least that is how I see it
• Andrew Stone: Sue -> The main purpose of the draft is to introduce
  eligibility into the model and influence the rules that control
  whether the candidate path is permitted to go active. Ex: it updates
  the rule chain in RFC9256 section 2.9
• there's no explicit precedence or priority between different
  protocol methods to set/unset the flag as it's influencing the CP
  object itself.
• i.e if someone uses netconf to change the flag, and PCEP undoes it,
  there's no independent management of the flag per protocol.
• The flag is generically usable, but different use cases / features
  would act on it based on their (the use case) rules
• Cheng Li: I am thinking that, if we can find some advantages against
  the local processing? a local processing is faster then PCE
• Cheng Li: When the Segment list is not available anymore, why don't
  we update the SR policy?
• Andrew Stone: Dhruv -> generic. For example, a use case in IDR the
  other day introduced admin flags to mark CPs as admin down for
  maintenance work. This could be used in that circumstance as well.
• Dhruv Dhody: Then lets update the drafts to reflect that
• Aijun Wang: My question is the same as the concern from Chengli
• Andrew Stone: Cheng -> the local vs PCE is dependent on use case.
  The one described here about the IGP / node SID case would invole
  local decision to mark ineligible (fast) and PCE to permit eligible
  (slow)
• Dhruv Dhody: or maybe i was looking at the wrong document
• Andrew Stone: Consider the TWAMP test case. Delay SLA is violated.
  If you remove the CP, you can't actually continue to measure when it
  goes back into compliance. If you keep it oper up but not elgiible
  to go active, you can continue to measure and permit it to go active
  once back in compliance. If you remove the CP -> you can't get that
  information
• Aijun Wang: I remembered there is some flag to indicate the backup
  CP?
• Andrew Stone: backup/protection is controlled by preference, not an
  explicit flag
• Cheng Li: do we have two SR policies? one for service traffic
  steering, another is for the TWAMP/BFD, etc.
• Susan Hares: @andrew-strone - RFC92566 section 2.9 deals with choice
  of active path. The preference is the primary choice, the 2.9 text
  reads like they are trying to imply protocol origin influences
  preference. It would seem that eligiblity would be useful for all
  sources (protocol origins). (Like setting the preference to
  "not-eligible'.
• Cheng Li: if a SR policy/segment list is reused/shared by multiple
  services, then we might have multiple SLA requirements. Then we
  might mark the flags for the FULL sid list(including the service
  SIDs), instead of the tunnel SID list? because we only have one bit,
  but multiple SLA requirements from multiple services.
• Andrew Stone: Sue -> yes, the preference is the primary choice, and
  the eligibility influences the boolean check if "is oper up and
  higher preference". I suppose you could consider the Eligible flag
  as being equivalent of "not eligible preference" (imagine negative
  values as a way to signal do not permit active) but this gives the
  additional flag without changing the behavior of preferencing
• Andrew Stone: Cheng -> I'm not totally following :). In the
  eligibility the simple scenario is one SR Policy with more than 1
  candidate path. If the SR Policy is used by multiple services, those
  services share the same SLA/constraints/behavior expectations of the
  transport tunnel. If not, they shouldn't be sharing the same SR
  Policy.
• Nat Kao: Can there be inconsistent eligible flags between the
  assigned value(from BGP/PCEP/Config CP) and the current status(ex:
  BGP-LS for the CP)?
• Cheng Li: I do not agree with this point. Think about 2 services,
  they are using the same segment list. They all require to use the
  lowest latency path, but one can set the bar of < 10ms, another is
  20 ms. When the latency is 15 ms, the service A will set the segment
  list as ineligible, but actually, it is still eligible for service
  B. Then should we set the flag?
• Susan Hares: @NAT +1 to your question.
• Andrew Stone: Nat/Sue -> imagine I have a CP advertised by BGP, and
  a CP advertised by PCEP. They have their own properties on them
  including SID lists. Those SID lists could be
  inconsistent/different. RFC9256 decides which one wins / order of
  selection when shared preference. Eligibility is just another
  attribute on the CP, which yes could be inconsistent between two
  records of CP of different origins. But the tie breaking of
  prefrence+origin rules isn't manipulated by eligibility (or at least
  not yet, perhaps we need to explore that in the draft)
• Ketan Talaulikar: @Shraddha, it is something continuous
• Andrew Stone: Cheng Li -> a key thing in your comment -> "service A
  sets it ineligible". There's no indication in the draft that the
  eligibility is controlled by services using the tunnel. It's
  controlled by the tunnel itself (locally) or the PCE which would
  also be tunnel specific. i.e it's about the config/parameters on the
  tunnel itself, not the consumers. There's no intent for individual
  services to control a flag on a shared resource. The tunnel controls
  itself based on it's own rules.
• For upstream consumers of the tunnel they need to be aware of those
  rules before selecting the tunnel
• Susan Hares: @andrew - So eligibility for user case 1 != elibility
  for use case 2? It is just a flag based on use case?
• Andrew Stone: correct
• Cheng Li: if yes, I need to rethink, why we need this flag for a
  tunnel. It seems weird to me
• Changwang Lin: draft-liu-spring-sr-policy-flexible-path-selection,
  perform validation on the segment list or CP, similar to BFD, even
  after switching to the new PATH, continue to monitor the old path.
  Perform the switchover on the device.
• Susan Hares: @andrew - is this a fast-failover switch for a tunnel?
  Sub-second stop?
• Andrew Stone: the use cases are example usages of the flag, but the
  actual definition of the flag is effectively a tool for N number of
  possible use cases/features. The Flag itself would be standardized
  as a concept in the model that influences whether a CP is permitted
  to go active
• Susan Hares: @andrew - p2mp as well?
• Andrew Stone: Sue -> (regarding fast-failover) not sure I follow the
  question. What happens when the eligibiltiy is changed is a local
  implementation detail (similar to someone changing the admin state
  to down, for example).
• (regarding p2mp) - good question, that never came up in discussion
  yet
• Andrew Stone: Changwang -> from a very quick skim of that document
  there certainly seems to be some similarities regarding influencing
  ability to go active, but maintain dataplane activity like BFD
  etc... I think the major difference is likely the exposure of
  eligibility as immutable property for operators/pce/local router
  itself
• • Nat Kao: @Andrew So the assigned value is from the RFC9256 best
    CP selection rule, while the current status(for reporting) is
    either the assigned value or the value modified by the headend?
• Changwang Lin: Andrew Stone-> Yes, this is the difference between
  draft-liu-spring-sr-policy-flexible-path-selection and
  draft-karboubi-spring-sr-policy-eligibility.
• Andrew Stone: Nat -> could you clarify what you mean by "assigned
  value is from RFC9256"? which value? Any reporting/state information
  would be the actual value currently assigned on the CP (which could
  have been changed locally or by PCE or a human at CLI)
• Boris Khasanov: I would also highlight the scalability and
  performance impact question, if router does need to monitor
  constantly many "inactive" CPs which still have actually active SLs
  inside which does not fit (may be temporary) some SLA/SLO..
• Changwang Lin: Should we define the behavior of the SR policy from
  the perspective of validity status or preferred eligibility
• Andrew Stone: Boris -> good point, except, I would say in normal
  operating procedures those CPs are there and being monitored anyways
  and already considered in the network design. If a use case doesn't
  want to use eligibility there's no need to use it and you can still
  withdraw/delete. Certainly would not be good to keep CPs oper up
  that have no hope of ever coming up. For example, I think it makes
  sense that if a CP is marked ineligible for a long period of
  unacceptable time, an alarm should be raised....
• Andrew Stone: ** let me correct -> keep CPs oper up that have no
  hope of ever going active
• Boris Khasanov: @Andrew, at some point yes, we may have BFD/S-BFD
  session per SL in each CP, but those sessions are usually UP only
  while traffic is forwarding via those SLs/CP, not during some
  "ineligible - unknown length" state...
• Nat Kao: @Andrew If I understand correctly, BGP/PCEP/Config assigns
  the eligible flags of the CP, while the headend can modify the flags
  after instantiating the CPs. Is that correct?
• Andrew Stone: Nat -> Yes, the intent would be local node can change
  the eligibility flag. I think I may see now you're question: how
  does the injected data (bgp/pcep/config) interwork with the local
  node setting/overwriting that data, to produce state (the actual
  eligible result) and how that is reported. Is this a correct
  interpretation? Will check with authors and perhaps we can explore
  in the document
• Andrew Stone: Boris -> agreed, certainly valid point
• Nat Kao: @Andrew Yes, exactly.
• Himanshu Shah: just checking the chat - a lot of activities. Agree
  with Andrew's responses to questions on the chat. I do hope this
  chat is preserved beyond this session we can continue to address the
  questions raised here and follow it up on the list.
• Himanshu Shah: I would recommend that same questions be also posted
  on the WG list, just in case, chat is lost post the session
• Alvaro Retana: Discussion on the list is always good. The discussion
  will be preserved...and can always be accessed through Zulip as
  well.
• Himanshu Shah: While the eligibility is a binary flag with various
  actors be able to set/reset the flag creating conflict on what the
  final action should be. I think we 'may' have create priority
  order?? We certainly need to discuss as the WG and amongst the
  authors what is the best remedy and clear guidance/verbiage to cover
  in the eligibility draft.

[10]: https://datatracker.ietf.org/doc/ draft-gong-spring-nd-advertise-srv6-locator/