[{"author": "Ketan Talaulikar", "text": "

There is a WG draft for per-algo adj-sid : https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/
\nIf 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.

", "time": "2023-03-27T01:09:33Z"}, {"author": "Weiqiang Cheng", "text": "

The similar solution for SRv6 is on the link: https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/

", "time": "2023-03-27T01:11:52Z"}, {"author": "Jie Dong", "text": "

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

", "time": "2023-03-27T01:19:10Z"}, {"author": "John Scudder", "text": "

Why even have a DIS, in other words, right?

", "time": "2023-03-27T01:21:18Z"}, {"author": "Jeff Tantsura", "text": "

+1

", "time": "2023-03-27T01:21:57Z"}, {"author": "Tony Li", "text": "

The only case would be a true L2 switch.

", "time": "2023-03-27T01:21:59Z"}, {"author": "Tony Li", "text": "

And you can have a switch with dissimilar port bandwidths.

", "time": "2023-03-27T01:22:19Z"}, {"author": "Les Ginsberg", "text": "

@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?

", "time": "2023-03-27T01:41:46Z"}, {"author": "Ketan Talaulikar", "text": "

@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?

", "time": "2023-03-27T01:42:28Z"}, {"author": "Ketan Talaulikar", "text": "

s/indication/ indication between planned/unplanned

", "time": "2023-03-27T01:44:11Z"}, {"author": "Les Ginsberg", "text": "

@Ketan. Yes - this is exactly my point.

", "time": "2023-03-27T01:44:39Z"}, {"author": "Jeffrey Haas", "text": "

BGP largely just wants to know \"is this nexthop reachable\".

", "time": "2023-03-27T01:45:52Z"}, {"author": "Ketan Talaulikar", "text": "

@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.

", "time": "2023-03-27T01:51:12Z"}, {"author": "Shraddha Hegde", "text": "

@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.

", "time": "2023-03-27T01:51:22Z"}, {"author": "Tony Li", "text": "

<TVR chair hat: on> 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.

", "time": "2023-03-27T01:54:33Z"}, {"author": "Les Ginsberg", "text": "

@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?

", "time": "2023-03-27T01:54:54Z"}, {"author": "Jeff Tantsura", "text": "

@tony - we already have BGP for that :)

", "time": "2023-03-27T01:56:53Z"}, {"author": "Ketan Talaulikar", "text": "

@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.

", "time": "2023-03-27T01:57:12Z"}, {"author": "Tony Li", "text": "

@Jeff BGP is not a dump truck.

", "time": "2023-03-27T01:57:30Z"}, {"author": "Jeffrey Haas", "text": "

TVR is the new dump truck?

", "time": "2023-03-27T01:59:09Z"}, {"author": "Tony Li", "text": "

TVR will be using the new dump truck, I hope.

", "time": "2023-03-27T02:00:04Z"}, {"author": "Shraddha Hegde", "text": "

@Ketan Is there a existing BGP mechansim that you propose people to use? Can you specify the draft/RFC

", "time": "2023-03-27T02:01:41Z"}, {"author": "Jeff Tantsura", "text": "

@ketan - what if you need to drain a P/transport router?

", "time": "2023-03-27T02:01:44Z"}, {"author": "Jeff Tantsura", "text": "

@shrada GSHUT

", "time": "2023-03-27T02:02:22Z"}, {"author": "Shraddha Hegde", "text": "

@Les Are you asking how does the ABR differentiate whether it should generate U bit or UP bit?

", "time": "2023-03-27T02:02:34Z"}, {"author": "Ketan Talaulikar", "text": "

@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.

", "time": "2023-03-27T02:03:30Z"}, {"author": "Aijun Wang", "text": "

@peter, the final solution should depend on the LSInfinity. The usage of LSInifinity should be temporary.

", "time": "2023-03-27T02:03:40Z"}, {"author": "Jeffrey Haas", "text": "

Ketan Talaulikar said:

\n
\n

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.

\n
\n

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.

\n

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.

", "time": "2023-03-27T02:04:10Z"}, {"author": "Les Ginsberg", "text": "

@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.

", "time": "2023-03-27T02:04:11Z"}, {"author": "Aijun Wang", "text": "

@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.

", "time": "2023-03-27T02:05:46Z"}, {"author": "Peter Psenak", "text": "

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.

", "time": "2023-03-27T02:07:51Z"}, {"author": "Ketan Talaulikar", "text": "

@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.

", "time": "2023-03-27T02:08:14Z"}, {"author": "Peter Psenak", "text": "

we want backward compatible solution and that can only be done with unreachable metric

", "time": "2023-03-27T02:08:21Z"}, {"author": "Peter Psenak", "text": "

and we do not want capability at all

", "time": "2023-03-27T02:08:30Z"}, {"author": "Peter Psenak", "text": "

it's very simple if you thing about it

", "time": "2023-03-27T02:08:52Z"}, {"author": "Shraddha Hegde", "text": "

@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.

", "time": "2023-03-27T02:09:04Z"}, {"author": "Les Ginsberg", "text": "

@Shraddha I understand the intent of the signalling. What I am asking for is a practical use case.

", "time": "2023-03-27T02:10:35Z"}, {"author": "Aijun Wang", "text": "

@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

", "time": "2023-03-27T02:10:51Z"}, {"author": "Jeffrey Haas", "text": "

Ketan Talaulikar said:

\n
\n

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.

\n
\n

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.

", "time": "2023-03-27T02:11:39Z"}, {"author": "Aijun Wang", "text": "

Anyway, for the perfect effect of solution, all the routers within the area should support such capabilities.

", "time": "2023-03-27T02:12:23Z"}, {"author": "Peter Psenak", "text": "

@Aijun, usage of LSInfinity is allowed by the protocol spec

", "time": "2023-03-27T02:12:30Z"}, {"author": "Aijun Wang", "text": "

I think it is just one placeholder function

", "time": "2023-03-27T02:12:57Z"}, {"author": "Peter Psenak", "text": "

@Aijun, I d not agree on that requirement

", "time": "2023-03-27T02:12:57Z"}, {"author": "Aijun Wang", "text": "

we can rely on it temporarily, not definitely. we should not enhance its usage

", "time": "2023-03-27T02:14:21Z"}, {"author": "Peter Psenak", "text": "

UPA is temporary by definition

", "time": "2023-03-27T02:14:51Z"}, {"author": "Aijun Wang", "text": "

the signaling function will be used definitely in future

", "time": "2023-03-27T02:15:28Z"}, {"author": "Peter Psenak", "text": "

Who said that>

", "time": "2023-03-27T02:15:41Z"}, {"author": "Aijun Wang", "text": "

there may be other usage of LSInfinity, we shouldn't mix such function with it. The sooner to detach from the LSInfinity, the better

", "time": "2023-03-27T02:16:57Z"}, {"author": "Tony Li", "text": "

If you're not going to somehow get the Path MTU to the end host, I don't see the point.

", "time": "2023-03-27T02:17:05Z"}, {"author": "Peter Psenak", "text": "

Usage of LSInfinity is clearly defined and can not chnage

", "time": "2023-03-27T02:17:19Z"}, {"author": "Jeffrey Haas", "text": "

Tony Li said:

\n
\n

If you're not going to somehow get the Path MTU to the end host, I don't see the point.

\n
\n

it's for ingress steered tunnels that need to calculate path mtu.

", "time": "2023-03-27T02:17:36Z"}, {"author": "Aijun Wang", "text": "

No, currently, the spec only states that the associated LSA shouldn't be used in SPF calculation

", "time": "2023-03-27T02:18:26Z"}, {"author": "Jeffrey Haas", "text": "

FWIW, there's work in BFD to help test mtu end to end.
\nhttps://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/

", "time": "2023-03-27T02:18:56Z"}, {"author": "Peter Psenak", "text": "

That's exactly what we need

", "time": "2023-03-27T02:19:08Z"}, {"author": "Weiqiang Cheng", "text": "

@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?

", "time": "2023-03-27T02:20:19Z"}, {"author": "Les Ginsberg", "text": "

@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\".

", "time": "2023-03-27T02:20:20Z"}, {"author": "Ketan Talaulikar", "text": "

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.

", "time": "2023-03-27T02:23:51Z"}, {"author": "Liyan Gong", "text": "

@Acee, About the question 1), i give you an example.
\nthere is a external lsa which has not been re-originated, and the router-lsa has been re-originated\uff08both sides are full\uff09, the result is that the external route is still wrong although the spf is right....
\nthe blackhole still occurs.

", "time": "2023-03-27T02:24:20Z"}, {"author": "QIANG Wang", "text": "

bypass my TTR topic \uff1f@Christian

", "time": "2023-03-27T02:24:30Z"}, {"author": "Les Ginsberg", "text": "

Huaimo - what you propose on slides 5/6 does not work since it does not support parallel links between neighbors.

", "time": "2023-03-27T02:25:19Z"}, {"author": "Aijun Wang", "text": "

if all the routers support such capabilities, we don't rely on it anymore

", "time": "2023-03-27T02:26:04Z"}, {"author": "Jeffrey Haas", "text": "

Les Ginsberg said:

\n
\n

@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\".

\n
\n

Agreed. I did say \"test\", not \"determine\".
\nPart 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.

\n

The motivation for the bfd large feature are things where the path is expected to work and doesn't, especially in wan environments.

", "time": "2023-03-27T02:27:37Z"}, {"author": "Liyan Gong", "text": "

@ Acee\uff0cabout 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.

", "time": "2023-03-27T02:29:03Z"}, {"author": "Les Ginsberg", "text": "

@Jeff - I have very limited enthusiasm for the MTU extensions because I think the use cases typically prove not of practical value.

", "time": "2023-03-27T02:29:08Z"}, {"author": "Tony Li", "text": "

Once more, with feeling: the IGP is not a dump truck. Services should be advertised in the management plane.

", "time": "2023-03-27T02:31:09Z"}, {"author": "Jeffrey Haas", "text": "

Les Ginsberg said:

\n
\n

@Jeff - I have very limited enthusiasm for the MTU extensions because I think the use cases typically prove not of practical value.

\n
\n

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...)

", "time": "2023-03-27T02:32:02Z"}, {"author": "Liu Yao", "text": "

@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

", "time": "2023-03-27T02:32:42Z"}, {"author": "Liu Yao", "text": "

draft-lz-lsr-igp-sr-service-segments

", "time": "2023-03-27T02:32:51Z"}, {"author": "Les Ginsberg", "text": "

@Jeff I don't object to the MTU draft - I just don;t have much enthusiasm for it.

", "time": "2023-03-27T02:33:22Z"}, {"author": "Tony Li", "text": "

@Andrew Alston That would be called a tunnel and making the controller an IGP speaker. Done.

", "time": "2023-03-27T02:34:58Z"}, {"author": "Jeffrey Haas", "text": "

Thank you, @Andrew Alston to lob that bgp-ls bomb at end of session.

", "time": "2023-03-27T02:35:02Z"}, {"author": "Ketan Talaulikar", "text": "

https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc7752bis#section-5.3.1.5
\nAnd similar for link and prefix attributes ... to put IGP info \"opaquely\" into BGP-LS.

", "time": "2023-03-27T02:36:23Z"}]