Chairs: Acee Lindem (acee@cisco.com)
Chris Hopps (chopps@chopps.org)
Secretary: Yingzhen Qu (yingzhen.ietf@gmail.com)
WG Page: http://tools.ietf.org/wg/lsr/
Materials: https://datatracker.ietf.org/meeting/115/session/lsr
Chairs (10 mins)
**Comments from Tony Li in chat:
Tony Li
00:09:59
Extended hierarchy should just die. Area Proxy should move to
experimental and do WG last call.
Yingzhen Qu (10 mins)
Acee: OSPF and ISIS YANG models are both bulk, after we have this,
it will be easier for people to know how to do YANG, xpath, etc.
Yingzhen: If you want to add YANG module into your draft and you
need help, please let us know and we'd be happy to help.
Chris Hopps: Does the extension cover all the published RFCs?
Yingzhen: We went over the RFCs published but not included in the
base module, we did skip a few unpopular ones though.
Acee: We need to check the protocol extension modules, such as BIER,
they have their standalone model
Yingzhen: I'll check.
Chris Hopps: Now the base models are published, it will be better if
we have YANG in the protocol extension drafts.
Yingzhen: In v1 of the IGP augmentations, most of these RFCs were
published before YANG started.
Acee: We also skipped experimental RFCs, such as OSPF TTZ.
Acee Lindem (10 mins)
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
Aijun: For non-routing information, we don't need flooding, only the
reliable mechanism. There are many reliable protocols, by using OSPF
you put the complexity to the operators if you consider the
interactions between the two instances. There is no deployment of
gen-app IS-IS.
Acee: The draft will have management considerations added, it
definitely has more configuration than you just put all information
into the base OSPF instance.
Aijun: One of your use cases is the MEC, and we expect to combine
the network info and the server info for routing.
Acee: I have to look at the application. if it's impacting routing,
it should be in the base OSPF.
Peter Psenak (10 mins)
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/
Chris: Are the implementations from the same vendor?
Peter: Single one for now, and there is one coming from a different
vendor.
Aijun: Firstly, from the definition of related RFC, LSInfinity just
indicated that the LSA that associated with LSInfinity shouldn't be
included in the SPF algorithm. That is to say, there will be no
specified Prefixes in the FIB, but that does not mean this prefix is
not reachable, because there may be other summary address covering
it that exists.
Secondly, there are already several usages of LSInifinity, we should
not complicate the situation again.
Thirdly, for OSPFv3, it is not appropriate to use the LSInifinity
value, or the metric of Summary LSA can easily exceed the value of
LSInifity, but the prefixes associated with the Summary LSA are
definetly reachable. Then depending solely on the LSInifity will
limit the operator for the setting of prefixes metric value.
We should take the explicit notification approach, as that defined
in PUA draft.
Peter: It's inifinity, and it means unreachable. In terms of using
it for other purposes you're probably referring to flex-algo, and we
have explicitly defined that these metrics are infinity metrics. I
don't see complexity, and we can argue forever. Please let other
people speak up.
Chris Hopps: We should get other people's opinions and we should
make a call.
Acee: Speaking as wg member, it needs to be standard track because
the ABRs need to have different behavior. This is the best from
backward compatible POV. The notification is ephemeral. Also from
deployment point, you only need to upgrade the router that needs to
act upon it.
John Scudder: Speaking as a contributor, isn't this a potential
application of OSPF-GT?
Peter: This is directly related to routing. You're right, not every
router needs it, the processing is up to the receiver.
Qiangzhou: There might be old devices in the network which don't
know what to do with LSinfinity.
Peter: You can only use it for unreachable, you can't use it for
anything else.
Qiangzhou: Huawei and Cisco devices have max-metric.
Peter: max-metric has different value. They basically do the same
thing. There is no conflict, but we can talk about it.
Ketan: LSinfinity has been in the protocol for decades, nothing
changes. What is added is the processing at the receiver to treat it
as an indication.
Huaimo: This is a hot topic. This is also used for aging out LSAs.
Peter: Aging out LSAs is done differently.
Huaimo: For metric close to infinity, is it reachable?
Peter: RFC says you can use LSinfinity or max-metric as max-age, but
the LSA itself is not max-aged. Any metric is valid and LSinfinity
has special meaning.
Tony Przygienda: we're solving the problem in the wrong protocol.
For all the solutions for this problem, this is the best. I will
keep this Informational, fundamental is that it doesn't scale. If we
push Standards Track, we may have to implement it and we need
operation considerations.
Peter: Agree with what you said. In terms of Standards Track, there
is some normative language. I hope we can keep it Informational.
Tony P: We're not changing the ABR behavior. The only thing we
mandate is the behavior of nodes on the wire. The idea of
interoperability means we define the observable behavior on the wire
as long as you comply with the specifications.
Peter: I'd like to make it informational if possible. I will let the
WG decide.
Acee: As chair, we can also do experimental.
Aijun: If the ABR wants to withdraw the specified prefix, but keep
the summary address that covers the specified prefix, it will send
the LSA with the metric of the specified prefix set to LSInifinity.
In such situation, the specified prefix is still reachable via the
summary address, then it can't trigger the switchover of BGP, or
some tunnel services.
Peter: Please describe the scenario.
Shraddha: When we summarize, we lose some information, like
reachability and metric. One common technique is to set the node
overload, and then advertise high metric so the PE can switch,
however this is lost when we summarize. We should look at these in
general instead of one by one.
Peter: Fair comment. Do you see the mechanism can be used?
Shraddha: Planned maintenance is different from unreachable.
Peter: If you have an idea, please propose.
David Lamparter: The behavior for very high metrics is not the same
for OSPF and IS-IS. The draft is accidently changing the behavior
for IS-IS with this high metric.
Peter: No, there is a section in the draft about this. The link
metrics are different, but this is prefix metric.
Dan Voyer: My comment, for the queue, as an operator or someone that
would use UPA, I prefer to be either "informational" (preference) or
track-ID (lease preferred) but definitely not "experimental"
Peter Psenak (5 mins)
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-flex-algo-reverse-affinity/
No questions asked.
Zhuo Yue (10 mins)
https://datatracker.ietf.org/doc/draft-yue-lsr-loop-detection-for-imported-routes/
Tony P: We should definitely not do it.
Chris: Les made the same comment.
Tony P: This is bad network design. You should do hierarchical IGP,
when you run out of hierarchy, you run BGP in 0.01% case. Well,
otherwise you start to build a distance vector protocol on top of
this whole thing.
Chris: In 0.01% case, you also have to config router wrong. This is
protecting misconfiguration.
Tony P: We're adding complexity to cover misconfiguration, and the
solution is not backward compatible.
Acee: Agreed with Tony. Routers don't work that way. You can use
tags for mutual redistribution. Tt works between different protocols
or same protocols. Don't waste time on OSPF extensions similar to
IS-IS ones.
Zhuo Yue: What we're trying to do is when routing loops happen, we
can use this to solve it.
Peter: Redistribution happens. The problem is valid, but not the
solution. We have existing mechanisms, and I don't think we need
this draft.
Liyang Gong (10 mins)
https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/
Acee: Speaking as working group member, I thought about this and I
guess either solution would work as long as we have the capability.
If you didn't have the capability, you can't just start using it
because many implementations use the reference bandwidth to compute
the interface cost so if there's an outlier link that's very slow,
it's going to have max-metric and all of a sudden these links would
be unreachable. Actually that's a reason not to use it even if the
capability is supported, because these links are going to be
auto-configured to max-metric. I think if we were to use max-metric,
we need to put a note in there that you should not ever use
max-metric when using reference bandwidth. I'll send my comments to
the list.
John Scudder: Solution #2 seems less a pain.
Ketan: I'd suggest authors to look at RFC 8770. The draft needs some
work in that direction.
Shraddha: I think this should be something done locally. If you
don't want to use a link in the default topo you advertise
max-metric for it, so alternate paths will be used. I don't
understand why you didn't think that is a solution.
Liyang: From our scenario, the link is newly added, if the cost is
smaller than other paths, it will draw traffic which is not what we
want.
Shraddha: I get your case. You should keep IGP metric high. To use
this, you will have to upgrade all routers. It's much easier just
use a different metric type.
Qiangzhou Gao (10 mins)
https://datatracker.ietf.org/doc/draft-liang-lsr-ospf-flowspec-extensions/
https://datatracker.ietf.org/doc/draft-liang-lsr-isis-flowspec-extensions/
Chris: You're configuring FW using IGPs. I understand BGP is a dump
truck, there might be case you need the info to be sent to a
different domain, it's not the case here. The CE1 to CE2 case is
crazy, you don't have Microsoft to config Google routers.
Les: I agree with Chris, it doesn't belong in the IGP. If you're
going to put this into IGP at all, OSPF-GT or ISIS gen-app is the
way to do it.
Jeff Haas: Agree with that this should be in OSPF-GT. I looked at
the encoding, it's clean. Are you comfortable with very large LSAs
going into IGP? BGP can have 4k in one PDU, I've seen the size of
2-3K flow spec filters. My impression is you don't want to put 2-3K
into an LSA.
Acee: If we were to do this in OSPF-GT, could we get away to not
redefine the flow-spec encoding and just use BGP encoding? If you
cannot, it's ok.
Jeff Hass: PCEP uses very similar to flowspec rules to carry it in
PCEP. There are bugs in the existing RFC. Please pay attention to
flowspec v2.
John Scudder: Thank you Jeff for mentioning PCEP option. We don't
want to put this into IGP.
=============================================================
Tony Li
00:09:59
Extended hierarchy should just die. Area Proxy should move to
experimental and do WG last call.
John Scudder
00:49:25
I put myself back in the queue as a proxy for Tony P.
Ketan Talaulikar
00:52:27
LSInfinity is not for aging out. Please recheck RFC2328
Ketan Talaulikar
00:52:55
It is just taking the prefix out of consideration. The LSA needs to
remain.
Ketan Talaulikar
00:53:28
Also, I see MAX METRIC for a link (0xFFFF) is being confused by
LSInfinity for a prefix?
Bruno Decraene
01:01:37
"out of consideration" and "unreachable" seems two different semantics
to me. IOW "out of consideration" does not seem to imply "unreachable"
Les Ginsberg
01:03:17
@Ketan +1 in regards to link metric vs prefix metric
Dan Voyer
01:03:51
my comment, for the queue, as an operator or someone that would use UPA,
I prefer to be either "informational" (preference) or track-ID (lease
preferred) but deffinitly not "experimental"
Christian Hopps
01:09:55
Thanks Dan, let's make sure that comment gets into the minutes
Tony Przygienda
01:15:26
yeah, one tag is a cheap hack for one hop
Tony Przygienda
01:15:40
if you have 2 hops you really have a problem because your chain is
looped
Louis Chan
01:17:04
If metric is advertised correctly across instances, metric value will be
high enough to avoid real looping.
Tony Przygienda
01:19:22
+1 Bruno: yes, the draft is swaying the meaning of "unreachable" from
"not advertised" to "advertised with infinite metric". Based on protocol
spec this is a distinction without behavior difference and this fact is
played cleverly
Martin Horneffer
01:19:25
BTW, I agree 100% to Peter. And I’m one of those who use tags and route
policies for this purpose.
Tony Przygienda
01:20:37
so kuddos to the sophists who found and use it ;-) The only problem is
really scalability AFAIS (I skip the double-clever flex-algo stuff doing
it as well and then using the "context", i.e. semiotics to actually
differentiate). If your head didn't explod yet I recommend some de
Saussure ;-)
Dan Voyer
01:22:50
@Martin H., yes, same here - we use tags and route-policies for this as
well
Tony Przygienda
01:25:08
@Louis: and your protocol preferences are hacked correctly and, and,
and. There is tons of broken glass you have to carefully step around
when you're doing this kind of stuff and 99.9% of customers are better
served by either hiearchical IGP or BGP'ing the whole thing.
Julien Meuric
01:43:52
PCE chair hat on: nicely put, @Jeffrey Haas
Jeffrey Haas
01:44:43
@Julien Meuric I'm still not sure the use case presented in LSR is a
good fit for pcep, but it's a good example of flowspec being used for
encoding support of the use cases.