Minutes IETF116: lsr: Mon 00:30
minutes-116-lsr-202303270030-00
| Meeting Minutes | Link State Routing (lsr) WG | |
|---|---|---|
| Date and time | 2023-03-27 00:30 | |
| Title | Minutes IETF116: lsr: Mon 00:30 | |
| State | Active | |
| Other versions | markdown | |
| Last updated | 2023-04-08 |
minutes-116-lsr-202303270030-00
IETF 116 LSR Minutes
Chairs: Acee Lindem (acee.ietf@gmail.com)
Chris Hopps (chopps@chopps.org)
Secretary: Yingzhen Qu (yingzhen.ietf@gmail.com)
WG Page: https://datatracker.ietf.org/group/lsr/about/
Materials: https://datatracker.ietf.org/meeting/116/session/lsr
1. Meeting Administrivia and WG Update
Chairs (10 mins)
2. IS-IS Fast Flooding
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/
Bruno Decraene (5 mins)
- Chris H: Any objection? No objection seen in the room.
- Acee: I’d encourage people to read the draft. There has been
significant updates, please review before WGLC.
3. 9:45-9:55 IGP extensions for Advertising Offset for Flex-Algorithm
https://datatracker.ietf.org/doc/draft-chan-lsr-igp-adv-offset/
Louis Chan (10 mins)
- Weiqiang Cheng: We had a similar draft in SRv6. It's necessary to
reduce the advertisement load to use flex-algo a in large network,
so I support this proposal. Do you have running code for it? - Louis: Not yet, but it's not complicated.
- Acee: I read the draft and I didn't know what virtual flex-algo is.
It was not explained in the draft. I think you got the term wrong,
it's another level of hierarchy, not flex-algo. It's all
implementation on the node. - Louis: It's not really vlan. Looking forward to a new name.
- Chris: The VLAN example helped me understand what "Virtual
Flex-Algo" meant at least. - Peter Psenak: I'm not sure how real the problem is unless you have
lots of flex-algos. Flex-algo is not a VPN technology, and the
number of flex-algos is expected to be a single digit. I don't think
it's needed, using two methods to advertise the same info. Also
agree with Acee, please change the name. - Louis: If there are 240 ports on a box, with vlans, it's a lot. We
do have customers fanning out at the aggregation layer, that would
be a lot. - Peter: But you don't run out of LSP space because of this. What's
the problem you're referring to? Running out of LSP space? - Louis: It's about scaling. Let's discuss offline.
- Peter: Typically we don't have two ways to do the same thing unless
it's a real problem. - Fang Gao: Question about load-balance between multiple algos and
protection is only for one algo. Can I use virtual flex-algo for
that? - Louis: Your question is about load-balancing, and this draft doesn't
solve that problem. The reason is like VLAN, it's not about
load-balancing. This draft is about QoS in one flex-algo. - Jie Dong: I'm trying to understand the problem. You want to have
more flex-algos or more links in one flex-algo? - Louis: Traditionally you advertise a label once per link, now once
for all links. The 2nd purpose is to have a single flex-algo but
subdivde it, just like a VLAN. - Jie Dong: This is different from flex-algo. We have a proposal for
scalability to use a shared topology. I will share the link. - Les Ginsberg: This draft skipped a few steps. It looks good from an
academic view, but it's not practical from an OPS POV. The virtual
flex-algo needs more discussions, which you introduced in a couple
sentences. That's my concern. - Louis: It's not a big trouble if you do careful planning.
4. IS-IS Traffic Engineering (TE) Metric LAN Extensions
https://datatracker.ietf.org/doc/draft-li-lsr-isis-te-metric-lan-extensions/
Chenxi Li (10 mins)
- Acee: How are you going to do bandwidth in a shared LAN? Why not use
a P2MP topology in IS-IS? - Chris: I have the same question. The routers are already treating
the interface as P2P, why not just use IGP P2P interfaces and you
don't need this extension? - Acee: If you do TE on a LAN, how to do bandwidth management?
- Chenxi: Later we may extend BGP-LS to report this info to NCE.
- Chris: Yes, but a BGP-LS extension draft and an IGP extension draft
can't justify each other's existence. BGP-LS and IGP both work by
simply modeling the network as P2P links, so we don't need this
extension. Let's take it to the list.
5. 10:24 IGP Unreachable Prefix Announcement
https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce
Peter Psenak (10 mins)
- Aijung Wang: Now Peter switched to explicit notification. in last
IETF, we have pointed out implicit is not sufficient, better use
explicit. We talked about merging, but we had different opinions
about which draft to be the base one. You acknowledge we found the
problem first, so we'd like to invite Peter to join our draft. - Chris: With chair hat on. Once it's a WG doc, it belongs to the WG.
We'd take the closest to the solution we want, not hang up on which
draft as the base. In the end we can have a single editor, not like
we're going to do that, just keep in mind it's not owned by a person
after it becomes adopted. - Peter: There are technical differences between the drafts. I fully
agreed it should be based on the solution, not who wrote it or who
started it. - Acee: As a chair, agreed with Chris. As a participant, consider
OSPFv3, using no unicast bit like flex-algo, then you'd have
complete backward compatibility and incremental deployment. - Peter: We can use existing mechanisms to make sure that nobody
interprets it as a reachable prefix, and we can use a new bit. - Acee: For the two proposals, that would give this one a clear
advantage. - Les: Between the planned and unplanned event, it's not clear to me
what the use case for this. If you have a planned event, you should
move all your traffic away from the destination before you take the
node out. Could you clarify what the use case for distinguishing
these two types of events? - Peter: This was proposed by Shraddha, maybe she can answer it.
- Shraddha: If it's a single domain, planned or unplanned events. For
planned, we can use overload, so traffic can move away. Similar use
case in multi-domain where summarization is in place, so traffic
can't be moved away based on metric. The new bit is to indicate it's
a planned event. - Bruno: Thank you for adding the flags to signal explicitly, however
the flags are informative. I think we need 3 scenarios: 1. explicit
prefix advertisement. 2. No reachability, or 3. Prefix with 1
metric. So far, you signal with max-metric, which is the same as no
advertisement. I think we have an issue with backward compatibility
because we have the same signal for two states. - Peter: I don't understand. We're not introducing new treatment.
We're adding a reason when sending max-metric. The draft says the
prefix can't be used for routing. I don't see backward compatibility
issue. - Bruno: Today I can advertise a prefix with max-metric, that doesn't
mean unreachable. - Peter: The draft clearly says if you advertise that specific metric,
then the prefix can't be used for routing. If you're advertising for
some other reason, my question would be if I have two
implementations sending max-metric for private reasons, how would
they interoperate? they wouldn't. - Chris: You're highlighting only one use case of "max metric". The
non-routing case for max-metric was not specified (on-purpose) there
may be other uses, right? - Peter: We're the first one.
- Chris: Should we leave room for a type to allow other uses of max
metric? - Chris: Bruno, your question would be this might be still reachable?
- Bruno: The way I read it, it will have reachability for the
less-specific prefix advertised. if I have reachability with /24,
and advertise unreachable for /32, I still have reachability for the
/32. - Chris: Some hardware doesn't support blackhole routes. This would be
so that BGP looks at it and picks a new next-hop. It's not really in
the forwarding plane. It's not intended to be. - Peter: Agree. It is not in the forwarding plane.
-
6. 10:45 Prefix Unreachable Announcement
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
Aijun Wang (10 mins)
-
Chris: We should continue with a merged solution.
- Acee: We should move on. The first proposal doesn't need all routers
to support it, the second does. You guys should talk and merge the
drafts. - Aijun: In PUA, we need capability negotiation, while UPA not.
-
7. 11:05 OSPF Adjacency Suppression
7.1
https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-suppress/Liyan Gong / Weiqiang Cheng (10 mins)
7.2 11:10 Alternative solution
Acee Lindem (5 mins) -
Liyan: I'm glad you agreed that it's a problem in OSPF. Two
questions about your proposal. First it's not only router-lsa, but
other types as well. Your solution doesn't work with other types of
LSAs. - Acee: yes, it does. Because you have the bidirectional link between
the routers, so you really only need to do router LSAs. Let's take
this to the list.
9. 11:14 IGP Extensions for Link MTU
https://datatracker.ietf.org/doc/draft-hu-lsr-igp-link-mtu/
Zhibo Hu (5 mins)
- Tony P: It's a self-inflicted problem, but I think the solution is
reasonable. - Louis Chan: How to guarantee the TI-LFA path also works? MTU may
change in this case. The second is that you need to signal the
client to lower the MTU before this one. - Zhibo: When calculating the TI-LFA path, the MTU is also considered.
- Louis: It's the transit, not the headend node, so you don't know.
- Chris: Let's discuss more on the list.
10. 11:20 IS-IS Extension for Big TLV
https://datatracker.ietf.org/doc/draft-chen-lsr-isis-big-tlv/
Huaimo Chen (5 minutes)
- Tony P: If we had green field protocol, this is possible solution.
However we have lots of stuff deployed in the wild. There is a
multi-TLV proposal, and we already have implementations. Also you
can't break in the middle of traffic engineering TLVs. If you have
an old router, the length field will be off. - Huaimo: For the length field, we'll need to adjust it. Regarding
implementation, we may have multiple solutions. - Chris: I think your solution would have made sense if it was green
field development, but probably doesn't work now. Let's take it to
the list.
11. 11:25 Advertising Service Functions Using IS-IS and OSPF
https://datatracker.ietf.org/doc/draft-xu-lsr-isis-service-function-adv/
https://datatracker.ietf.org/doc/draft-xu-lsr-ospf-service-function-adv/
Hongyi Huang (5 mins)
- Fang Gao: Do you need an ID for normal SF or SR policy, or is it
identified by the SID? - Hongyi: What you said is feasible.
- Andrew: Why not we look at some shim to transport IGP data directly
there? - Ketan: It's already in BGP-LS.
- Chris: That's a big topic.
- Acee: we may consider an interim.
- Chris: yes, we'll consider an interim.
The following presentations didn't happen.
-
Route Redistribution Credibility ID for Avoiding Routing Loop
https://datatracker.ietf.org/doc/draft-wang-lsr-redistribution-credibility-id/Qiang Wang (5 mins)
================================================
### If time permitting
================================================
-
Stub Link Attributes
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/Aijun Wang (10 mins)
Total: 120 mins
Chat History
-
Ketan Talaulikar
00:39:39
There is a WG draft for per-algo adj-sid :
https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/If we have large number of links, we are advertising many other
attributes per link - so I am also missing the point of
"compressing" only the adj-sid advertisement.
* Weiqiang Cheng
00:41:58
The similar solution for SRv6 is on the link:
https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/
* Jie Dong
00:49:16
The draft I mentioned which provide better scalability for this use
case is:
https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-08
* John Scudder
00:51:24
Why even have a DIS, in other words, right?
* Jeff Tantsura
00:52:03
+1
* Tony Li
00:52:05
The only case would be a true L2 switch.
* Tony Li
00:52:25
And you can have a switch with dissimilar port bandwidths.
* Les Ginsberg
01:11:52
@Shraddha. Sorry - I do not understand your point. If I am an ABR in
another domain, when I receive the UPA - why would I treat it
differently if it was planned vs unplanned. Can you clarify the
practical use case?
* Ketan Talaulikar
01:12:34
@Shraddha Hegde For multi-domain scenario, I would expect that for
BGP services on top, the operator would switch to the redundant peer
using BGP attributes for planned events? So is there really the need
for an indication between planned/unplanned within the IGP?
* Ketan Talaulikar
01:14:17
s/indication/ indication between planned/unplanned
* Les Ginsberg
01:14:45
@Ketan. Yes - this is exactly my point.
* Jeffrey Haas
01:15:58
BGP largely just wants to know "is this nexthop reachable".
* Ketan Talaulikar
01:21:18
@Jeffrey Haas , correct. So if I am doing maintenance on a router, I
would do like to indicate this to other BGP speakers using some BGP
attribute (e.g. local pref). Similar to OVL for ISIS. My point is
that using this IGP spec for indication of planned events is does
not seem like a good idea to me.
* Shraddha Hegde
01:21:28
@Ketan In MPLS deployments people use underlying igp metric to shift
the traffic away. With introduction of UP indication, the same
mechanism can be used where summarization is in place.
* Tony Li
01:24:39
TVR WG is going to be working on a way of
distributing planned topology changes. It is my hope that we find a
better mechanism than IGP flooding for this information.
- Les Ginsberg
01:25:00
@Shraddha - I am not objecting to using the IGP for UPA - I am
asking for clarification on the practical use case for
differentiating between planned/unplanned on the remote ABR. Can you
please provide a real deployment case? - Jeff Tantsura
01:26:59
@tony - we already have BGP for that :) - Ketan Talaulikar
01:27:18
@Shraddha Hegde , sure and I understand. However, I would recommend
a more robust BGP based mechanism for indication of planned event
for BGP services. Especially in this specific scenario. We should
remember that given BGP scale, a BGP based mechanism done before the
actual maintenance would be far better. Putting such things in this
IGP spec might give a false/wrong (?) impression to some ... UPA is
best used for failures (unplanned) and not for planned events. - Tony Li
01:27:36
@Jeff BGP is not a dump truck. - Jeffrey Haas
01:29:15
TVR is the new dump truck? - Tony Li
01:30:10
TVR will be using the new dump truck, I hope. - Shraddha Hegde
01:31:47
@Ketan Is there a existing BGP mechansim that you propose people to
use? Can you specify the draft/RFC - Jeff Tantsura
01:31:50
@ketan - what if you need to drain a P/transport router? - Jeff Tantsura
01:32:28
@shrada GSHUT - Shraddha Hegde
01:32:40
@Les Are you asking how does the ABR differentiate whether it should
generate U bit or UP bit? - Ketan Talaulikar
01:33:36
@Jeff Tantsura , the P/transport router is doing forwarding based on
summary. So it does not need to perform any action on the UPA - at
least not in the forwarding. - Aijun Wang
01:33:46
@peter, the final solution should depend on the LSInfinity. The
usage of LSInifinity should be temporary. - Jeffrey Haas
01:34:16
Ketan Talaulikar said:
Jeffrey Haas , correct. So if I am doing maintenance on a router, I
would do like to indicate this to other BGP speakers using some BGP
attribute (e.g. local pref). Similar to OVL for ISIS. My point is
that using this IGP spec for indication of planned events is does
not seem like a good idea to me.
I've not been strongly following the UPA work so I don't have well
considered opinions on it at this point. That said, methodologies to
shift traffic from a nexthop in a network-wide graceful mechanism
with a small number of events are appreciated.
Doing similar via locally attached attributes in BGP ("drain
procedures" or similar) is certainly current practice. However, so
is dealing with potentially long convergence times when this is
done. - Les Ginsberg
01:34:17
@Shraddha, No. I am asking what the ABR would do differently based
on the state advertised. If it was a planned event and the ABR
already knew about it from some other TBD means, it would not matter
of the ABR reacted to the received UPA since it would have already
moved traffic away from that host anyway. - Aijun Wang
01:35:52
@Acee, PUA soultion prefer to all routers to support such
capabilities, but it can also be deployed incrementally, with the
help of LSInfinity, or other mechanism. - Peter Psenak
01:37:57
you are contradicting yourself Aijun. You are saying you do not want
to use unreachable metric, but then you use it to suppress the
capability. - Ketan Talaulikar
01:38:20
@Jeffrey Haas , precisely due to the long convergence time, this
should be done using BGP based indication well before the actual
maintenance work is done. UPA is a trigger after failure. More
specifically, my concern with the explicit indication of UPA for
planned events is that it would seem to recommend this kind of usage
while in fact BGP based mechanism is desirable. - Peter Psenak
01:38:27
we want backward compatible solution and that can only be done with
unreachable metric - Peter Psenak
01:38:36
and we do not want capability at all - Peter Psenak
01:38:58
it's very simple if you thing about it - Shraddha Hegde
01:39:10
@Les Its the PE that would process the notification (U bit or UP
bit)differently. The difference in processing is control plane vs
data plane. - Les Ginsberg
01:40:41
@Shraddha I understand the intent of the signalling. What I am
asking for is a practical use case. - Aijun Wang
01:40:57
@peter, The usage of LSInfinity should be removed from the network,
not to enhance it. Relying on the capabilities negotiation, the
operator can know the support status of routers within the area - Jeffrey Haas
01:41:45 - Ketan Talaulikar said:
Jeffrey Haas , precisely due to the long convergence time, this
should be done using BGP based indication well before the actual
maintenance work is done. UPA is a trigger after failure. More
specifically, my concern with the explicit indication of UPA for
planned events is that it would seem to recommend this kind of usage
while in fact BGP based mechanism is desirable.
If the network is told "this bgp nexthop is unusable", routers
across the network can converge more quickly because each router
will locally find alternate paths, if available. If you source this
solely at the point of "maintenance", you rely on full path hunting
across the AS to finish. - Aijun Wang
01:42:29
Anyway, for the perfect effect of solution, all the routers within
the area should support such capabilities. - Peter Psenak
01:42:36
@Aijun, usage of LSInfinity is allowed by the protocol spec - Aijun Wang
01:43:03
I think it is just one placeholder function - Peter Psenak
01:43:03
@Aijun, I d not agree on that requirement - Aijun Wang
01:44:27
we can rely on it temporarily, not definitely. we should not enhance
its usage - Peter Psenak
01:44:57
UPA is temporary by definition - Aijun Wang
01:45:34
the signaling function will be used definitely in future - Peter Psenak
01:45:47
Who said that> - Aijun Wang
01:47:03
there may be other usage of LSInfinity, we shouldn't mix such
function with it. The sooner to detach from the LSInfinity, the
better - Tony Li
01:47:11
If you're not going to somehow get the Path MTU to the end host, I
don't see the point. - Peter Psenak
01:47:25
Usage of LSInfinity is clearly defined and can not chnage - Jeffrey Haas
01:47:42
Tony Li said:
If you're not going to somehow get the Path MTU to the end host, I
don't see the point.
it's for ingress steered tunnels that need to calculate path mtu. - Aijun Wang
01:48:32
No, currently, the spec only states that the associated LSA
shouldn't be used in SPF calculation - Jeffrey Haas
01:49:02
FWIW, there's work in BFD to help test mtu end to end.
https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ - Peter Psenak
01:49:14
That's exactly what we need - Weiqiang Cheng
01:50:25
@Acee Two questions: 1) For other type of LSA such as Type 5 LSA,
How your solution works? 2) Your solution is the second solution in
Liyan's presentation. As Liyan mentioned, it will cause statemachine
changed. Is that more complicated solution than Liyan's solution,
right? - Les Ginsberg
01:50:26
@Jeff I think the purpose of the BFD draft is different. It is to
test whether the link works. It is not for "MTU discovery". - Ketan Talaulikar
01:53:57
Regd https://datatracker.ietf.org/doc/draft-hu-lsr-igp-link-mtu/ ...
there is value for this information to be advertised as part of the
topology information. Like TonyP said, there are cases of such "self
inflicted wounds" out there. However, I don't think the IGP spec
should go beyond that advertisement part. Path MTU and other aspects
related to the usage of this link MTU info are better discussed
separately. - Liyan Gong
01:54:26
@Acee, About the question 1), i give you an example.
there is a external lsa which has not been re-originated, and the
router-lsa has been re-originated（both sides are full）, the result
is that the external route is still wrong although the spf is
right....
the blackhole still occurs. - QIANG Wang
01:54:36
bypass my TTR topic ？@Christian - Les Ginsberg
01:55:25
Huaimo - what you propose on slides 5/6 does not work since it does
not support parallel links between neighbors. - Aijun Wang
01:56:10
if all the routers support such capabilities, we don't rely on it
anymore - Jeffrey Haas
01:57:43
Les Ginsberg said:
@Jeff I think the purpose of the BFD draft is different. It is to
test whether the link works. It is not for "MTU discovery".
Agreed. I did say "test", not "determine".
Part of the headache for these MTU mismatch headaches is thinking
you've done the right thing to get a particular path mtu... then
finding out it doesn't actually work.
The motivation for the bfd large feature are things where the path
is expected to work and doesn't, especially in wan environments. - Liyan Gong
01:59:09
@ Acee，about the problem 2), it is equivalent to abandon the action
of the DD exchange, huge midification to the basic ospf protocol,
and may cause extremely pressure and risk to all the routers in the
network. - Les Ginsberg
01:59:14
@Jeff - I have very limited enthusiasm for the MTU extensions
because I think the use cases typically prove not of practical
value. - Tony Li
02:01:15
Once more, with feeling: the IGP is not a dump truck. Services
should be advertised in the management plane. - Jeffrey Haas
02:02:08
Les Ginsberg said:
@Jeff - I have very limited enthusiasm for the MTU extensions
because I think the use cases typically prove not of practical
value.
I'm sympathetic. But MTU issues exist and some networks can't use
the one MTU to rule them all. (And in the outage find them...) - Liu Yao
02:02:48
@Hongyi Huang We also have a IGP service function draft trying to be
consistent with BGP-LS by advertising the SF function info as the
property of SIDs instead of routers - Liu Yao
02:02:57
draft-lz-lsr-igp-sr-service-segments
Les Ginsberg
02:03:28
@Jeff I don't object to the MTU draft - I just don;t have much
enthusiasm for it. - Tony Li
02:05:04
@Andrew Alston That would be called a tunnel and making the
controller an IGP speaker. Done. - Jeffrey Haas
02:05:08
Thank you, @Andrew Alston to lob that bgp-ls bomb at end of session. -
Ketan Talaulikar
02:06:29
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc7752bis#section-5.3.1.5And similar for link and prefix attributes ... to put IGP info
"opaquely" into BGP-LS.