Minutes IETF102: lsr
Link State Routing
||Minutes IETF102: lsr
LSR WG Agenda IETF-102
Time Slot (150m): Monday, July 16, 2018 09:30-12:00 EDT
Chairs: Chris Hopps and Acee Lindem
Secretary: Yingzhen Qu
- Intro, Adminastriva, Document Status
o Presenter: LSR Chairs (Christian Hopps, Acee Lindem)
Les: 7810bis is not an RFC yet. we’d like to progress it fast.
- Yang Updates
o Presenter: Yingzhen Qu
o Document: https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/
o Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-yang
o Document: https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/
o Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/
Chris: I’d like to have both OSPF and ISIS progress together.
Acee: Considering the size of the documents, maybe better to progress
them consecutively. Instead of sending 240 pages document,
120 is probably preferred.
Chris: I want to send both because if something wrong found in
one document, it can be fixed in both.
Jeff Hass: Considering what’s happened for BFD model, I’d suggest one
at a time. Otherwise you may get lots of unusual comments,
and it’s easier to get them resolved before sending the doc.
Yingzhen: The authors are actively working on both documents and address
Chris: I just don’t want to see an extra meeting added to this process.
- OSPF Link Traffic Engineering (TE) Attribute Reuse
o Presenter: Peter Psenak
o Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse
Peter: Should be ready by next IETF for LC.
No question asked.
- IGP Flexible Algorithm
o Presenter: Peter Psenak
o Document: https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo
Acee: Would it be possible to specify a loopback for each service
and use Flex algorithm w/o segment routing?
Peter: By loopback you mean specific address?
Peter: You can. The intention is you don’t have to.
Acee: That would have be described in a separate IP-only draft.
Acee: Speaking as Chair, I was not asking for this draft. It was
- Dynamic Flooding on Dense Graphs
o Presenter: Peter Psenak
o Document: https://datatracker.ietf.org/doc/draft-li-dynamic-flooding
Acee: Is there an implementation done or underway?
Peter: We’re looking at it.
Acee: For these last two flood reduction, people are look at implementations.
Peter: This is a generic solution for any arbitrary topology.
Chris: Doesn’t multicast give you this kind of tree?
Acee: It’s not reliable.
Peter: You may come up with a spanning tree, but you want more, at
least a bi-connected flooding tree. This is more interesting.
- IS-IS Extensions to Support Routing over IPv6 Dataplane
o Presenter: Peter Psenack
o Document: https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions
Acee: So for routers which don’t support this, will it install a route based on
Peter: The router will see two different TLVs, reachability tav is preferred,
but the result is the same.
Jie Dong: Question about End.X SID sub-TLV. I see algorithm is added. In SR-MPLS,
the algorithm is applicable only to prefix SID.
Peter: In SRv6, the address is global. Although the locator SID has algorithm,
we also added it here, it’s for consistency. You have certain locators
which you want to use for a certain algorithm, but the end SID would
actually fall from forwarding perspective, which will be part of a
different locator and for a certain algorithm. You want to make sure
you have a strict association. So, by specifying algorithm here you make
sure that you're not going to use the wrong locator during the
transition. That's basically the reason.
Jie: So, if there's any inconsistency between these sub-TLV and the locators
algorithm, which one will be preferred?
Peter: Basically what you say is if I have a locator which is for a certain
algorithm, I make sure that this one will pick that one and not the
other one. For example, if you for some reason remove that locator
that this one may fall into a different locator, so it is like you want
this it to be algorithm five but it will fall back from the forwarding
perspective. The best match would be something the locator which is of
algorithm six. You don't want that to happen, you want to make sure that
you pick the right locator so that's the reason why we have the algorithm
Sue Hares: Have you worked with BGP to make sure the changes are correct?
Peter: If you mean BGP-LS, yes.
- Restart Signaling for IS-IS
o Presenter: Les Ginsberg
o Document: https://datatracker.ietf.org/doc/draft-ginsberg-isis-rfc5306bis
Chris: Does anybody object? No. Do people support? (a tleast 1/2 the
room raised their hands). We’ll ask on the list.
Comment from Jabber, no slides number.
- IS-IS Routing for Spine-Leaf Topology
o Presenter: Naiming Shen or Les Ginsberg
o Document: https://datatracker.ietf.org/doc/draft-shen-isis-spine-leaf-ext
Acee: We have lots of discussion on flood reductions. Chris and I are
discussing strategy. We’d like to ask WG on how to progress them and
deploy them? You want to add about requirement?
Chris: We got lots of solutions. So I’m wondering how we pick? Or let the
market decide? How to best progress?
Jeff Hass: I didn’t follow this draft. My question is if you end up
with different topologies. How could this be applicable? One of
the things we've seen in the presentations including the open
fabric presentation, is that other topologies are being explored
for things. my question/comment to you all is this is optimized for
that situation. If you end up with a different topology other than
CLOS, how does this feature potentially interact with those? So as
you consider do extensions you know consider how it might actually
interact if you try to deploy it a different topology.
Acee: I think this one is simpler that it's just between tier 0 and tier 1,
so it's not limited to CLOS.
Jeff Hass: Right and that's going to be probably the the single most common
thing when you look at the other topologies know is when you get
no an extra layer to up that it becomes more interesting. But my
suspicion based on how this is seems to be presented is that the
generalization of here's how it apply for the next levels are you
actually doing Auto provisioning though otherr topologies. So
you have basically the easy mode for clos and therefore you're
going to have to know this is your levels 1 and 2, and that they
auto-discover each other and can tell that they're miss wired.
Acee: Zero touch provisioning it is targeted clos.
Chris Martin: I was just gonna say that if you look at the agenda we still
have I think two or three more presentations that cover areas
like this and that doesn't include what's happening, for
example, in RIFT. So going back to your point, in terms of how
the market looks, at this point I would say that there's really
what I mean from my view and just Jeff just mentioned this as
well. There are at least four different approaches that are
really tied to CLOS, and then there's maybe one or two that are
in terms of generic topology. So maybe we look at them as they
apply to them maybe the bigger use case which is leaf/spine or
CLOS, and then you know the generic use case which is arbitrary
topologies, and then let's decide there. Because there obviously
is a big need for addressing this problem, and I just going back
I mean having these discussions over the past couple years,
we're trying to solve a flooding problem that's limiting link
state protocols being used in leaf/spine or in clos topologies.
If that's what we're trying to do, then that should be the
fundamental requirement. you know a lot of the work that's
coming out now over the past five years has been to try to fix
the flooding problem, so we have BGP being used to fix flooding.
When now it looks like everybody said well maybe we should just
fix the flooding problem. So if that's the fundamental
requirement I don't know if Chris is what you're suggesting that
we go to a requirements document first, to try to solve flooding
problems in IGPs. if that I mean I’ve seen a presentation at
Manoa in 2000 and it was this comparative anatomy presentation.
And basically there's a problem with scale is reduces really to
flooding this is almost 20 years ago, and there's been no attempt
made, so if that's really where we're trying to do then why we just
focus on that.
Chris Hopps: I don't know whether we go to do a requirmemnts document or not, or
if it's enough to just talk on the list. But I think especially
when you get competing solutions, and try to pick one, then
sometimes requirements document helps focus on that. But I don't
know if we're there yet.
Russ: My take on this is I'm much preferential to having unified signaling
than a unified solution at this moment. Because there are different scales
and different kinds of topologies like Chris said, and Acee said that.
You know we need to look at and I would just prefer for the moment just to
get on the path of having unified singnaling and let's not worry about
which solution is best depending on what happens in the marketplace, and
where things go in the future. Because I'm not convinced that a
requirements document is needed and I'm not certain that a requirements
document is gonna be able to capture like operational realities in a way
that's gonna have to be helpful in the long term.
Jeff T: We started DC Routing a few IETFs back. As a result, we have two new
WGs. I don’t think the end goal is to address the problem for
specific topology. We should focus not only on flooding, but a new
protocol on particular topology and see how it fits.
Dino: Leaf/Spine topology has a big market. If you want to fix this problem
in simple but large scale, have you considered static routing? ECMP and
static routing will take you a long way.
Chris H: Yes.
Acee: A lot of these Controller-based solutions basically are
static routing. It's just more dynamic than in the past.
Dino: In SDN, what controllers do are in management plane to configure static
routes. It was “ ip route” command in the 90s.
Naiming: This proposal is very similar to static routes. You actually install
two static routes.
Tony P: The links still fails. The problem is you need to split whether you
have a direct topology or generic topo. If you work on that stuff, I
think you have to keep it apart, I think in the north/south direction,
the topology is actually quite tractable, and there's a couple of
different proposal of different properties. the generic problem has
been walked for twenty with by multiple people with poor results. and
I do not think that the results were improved because nothing new in
graph theory and the properties you will find hot links and so on and
so on are still in place. Whether the north-south is more immediate
and I think it's much more tractable so it's kind of meta input.
Naiming: Yeah, agreed. It's more into like the first tier fully mesh.
Acee: Let’s start this on the list.
- Preferred Path Routing (PPR) in IS-IS/OSPF
o Presenter: Uma Chunduri
o Document: https://datatracker.ietf.org/doc/draft-chunduri-lsr-isis-preferred-path-routing
o Document: https://datatracker.ietf.org/doc/draft-chunduri-lsr-ospf-preferred-path-routing
Acee: So the selection of preferred path is separate work? How do you
know which subset of paths you’re going to do preferred path?
Uma: PCE does the calculation like SR.
Acee: This draft covers only the dataplane and the advertisement of
Ketan: Isn’t this similar to RSVP-TE path, but populate the paths in IGP?
It’s flooded across the domain and program the data plane. It’s
really flooding N**2 paths across the domain?
Uma: You don’t have to advertise the path if there is no issue with SPF
Ketan: Let’s say if there are 1000 paths, they will be flooded in the IGP
domain. It’s really RSVP flooded by IGP.
Uma: in RSVP, you don’t flood.
Ketan: In RSVP, it’s only flooded to this hops, but you’re flooding
Acee: Let’s take it on the list.
Dino: #1 - Overwhelmed by the complexity. #2 - Your tax overhead was
completely understated, #3 - I think you have to build new machinery
to reinvent MPLS in a more complicated way. This is just my opinion
and you could take it or leave it, doesn’t matter. You could have
solved this problem with straight source routing, with not every
hop-by-hop as the SID. You just could have found a repair path input
one entry in the source route to get around the failure and that would
have taken you a long way.
Uma: It’s not only for FRR. FRR is a by-product.
Dino: the basic stuff is complicated, and there is more coming.
Chris: Let’s take it on the alias.
Acee: Do you want to start a discussion on the alias?
Uma: Yes. We’re ready.
- IGP Extensions for Segment Routing based Enhanced VPN
o Presenter: Jie Dong
o Document: https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/
Peter: Biven MTR is available, obviously you can use it. My question is
how’s the scalability? How many slices are you thinking of? You
have too provision on each interface. There might be alternative
solutions that can achieve the same thing in a better way.
Jie: Let’s discuss it offline. The scalability of MTR is depending on the
number of slices you have. We may see whether some optimization
Dino: I have a general statement not just about this presentation. I see
maybe every five years, IGP is being used to ship the information
across the network. You store it in LSPs in the middle of a network
while nobody is using it but only the edge. We saw this long time
ago with IBGP, and put in route reflectors. We need a reliable
mechanism. Running multicast on edge for transport. There are only
so many possible ways to do routing. People are taking all possible
Stewart: I agree we need a general purpose way to propagate the message,
but we do need to move along and ISIS seems to be a good
solution in short term. We should separate the problems in long
Chris H: Just want to clarify, Dino meant you may want to have it only
on the edge routers not the center of the network.
Dino: You have no flexibility because you have to change all routers.
Stewart: This case it’s needed on all routers.
Dino: Another way to think about it is to use mapping system.
Stewart: For this particular application, we need it everywhere for
traffic engineering to steer traffic.
Acee: Because you’re doing resource reservation, you need not only edge
routers to have the state.
Stewart: We will need to introduce more states. it’s about particular
Jeff T: We have it presented in RTGWG several times. We need a more
structured way. You may not want to flood it everywhere.
Acee: TRhe base network slicing should advance before this one, correct?
Acee: I’d advise people to read this draft. But we’re dependent on the
progress of the base draft in SPRING?
- OSPF Extend for Inter-Area Topology Retrieval
o Presenter: Aijun Wang
o Document: https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-inter-area-topology-ext/
Acee: There is some history. We rejected a long time ago overloading OSPFv2
TOS bits for other purpose. All those using non-TLV proposals were
rejected. I think Padma had a proposal a long time ago reusing TOS
and we didn’t do it. At that time we didn’t have a way to extend ospfv2,
now we should only use TLV.
Chris H: You should just use TLV.
Ketan: We shared comments offline. I think some of the non backward-compatible
were addressed. Like Acee mentioned, we should use TLV. I’d support the
use of source router id TLV.
Acee: You can look at the use case, it might be weak. This could be used for
other things, but please use TLV.
Peter: I think we can use the source router id, but I don’t think it fixes
what you’re trying to solve. Because what you advertised is prefix
and you associate it with the Router ID. but what you have seems to
try to do if I understood it from the layout, you are trying to
reconstruct the topology but there's no topology data it's just the
prefix. So I don't know how are you going to use this to reconstruct
any topology data.
Jie: Let’s take it offline. How to use the topology and prefix together.
- IS-IS Support for Openfabric
o Presenter: Russ White
o Document: https://datatracker.ietf.org/doc/draft-white-openfabric/
Chris: I just want to clarify that we didn’t want to have any requirement
document, that seems like a over kill.
Russ: That’s fine.
Acee: This seems to be a separate track because it diverges enough from
standard IS-IS. Maybe it can be experimental? Have you considered
Russ: Yes, we considered checksum. This should not matter.
Christian: Flooding scope is not impacted by the checksum.
Russ: If you have more questions, take them to the list.
Chris: Do we have anybody with interop lab? To test these different
algorithms? Maybe publishing paper?
Russ: This is actually modeled using the same model as OSPF MANET. This
is pretty much already deployed and running.
Acee: OSPF MANET is much more complex than this one.
- OSPF Flooding Reduction
o Presenter: Huaimo Chen
o Document: https://datatracker.ietf.org/doc/draft-cc-ospf-flooding-reduction/
Les: We have two presentations saying the same thing. From WG
perspective, we should not progress two documents.
Acee: Intuitively Tony’s is better. You’re reverting back to normal
flooding when you have more load in the network. You’re saving
flooding when the flooding topology doesn't change.
Huaimo: In that case, we have different solutions. we use those links
to guarantee when one critical node is down, we use those
links. In between some of the nodes are doing normal flooding,
most of nodes are still optimized.
Chris: Second what Les is saying, we don’t need two proposals for
the same thing.
Huaimo: Tony’s original proposal was centralized, and mine was
distributed. Now Tony has distributed mode. There are
more modes now.
Chris: Maybe there are room for working together.
Chris: Isn’t static configure work better?
Huaimo: Static config is fine. we provide more options for