Early Review of draft-li-arch-sat-04
review-li-arch-sat-04-rtgdir-early-lindem-2024-02-06-01
Request | Review of | draft-li-arch-sat-02 |
---|---|---|
Requested revision | 02 (document currently at 09) | |
Type | Early Review | |
Team | Routing Area Directorate (rtgdir) | |
Deadline | 2024-02-12 | |
Requested | 2024-01-12 | |
Requested by | Eliot Lear | |
Authors | Tony Li | |
I-D last updated | 2024-02-09 | |
Completed reviews |
Rtgdir Early review of -04
by Acee Lindem
(diff)
|
|
Comments |
Review guidelines for independent submissions can be found at https://www.rfc-editor.org/about/independent/. Thanks in advance. |
|
Assignment | Reviewer | Acee Lindem |
State | Completed | |
Request | Early review on draft-li-arch-sat by Routing Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/rtg-dir/pjBQSUfRvhWpTtHGQnWce3sTxKg | |
Reviewed revision | 04 (document currently at 09) | |
Result | Ready | |
Completed | 2024-02-09 |
review-li-arch-sat-04-rtgdir-early-lindem-2024-02-06-01
Hi Tony, This would certainly be an interested experiment to build a large-scale IS-IS routing domain using this architecture. I’m fine with the document - see inline. > On Feb 8, 2024, at 8:04 PM, Tony Li <tony.li@tony.li> wrote: > > > Hi Acee, > > >>>> 1. In section 2.3, would it make sense to include in the last >>>> paragraph that the deployed IGP are not suitable for large scale >>>> satellite networks and then go on to forward the IS-IS >>>> considerations? >>> >>> >>> I’m sorry, I’m not sure I understand the question. In that section, we try to articulate why >>> we find OSPF to be an awkward fit for satellite topologies, where there is no central >>> backbone to work with and why IS-IS is a better fit. >> >> >> So, why is an IS-IS L2 area connecting L1 areas so different from an OSPF backbone >> connecting non-backbone areas? Without using IS-IS area proxy, I don’t see the advantage. > > > > First off, you’re correct, without area proxy, this doesn’t work. It explodes quite badly and I would not propose doing things that way. You would end up with all nodes flat in L2, which doesn’t scale. No donut. > > Now, as to OSPF, as you know, that’s not my expertise, but my understanding is that without resorting to virtual links, you end up with areas that are tangential to the backbone. This is difficult in the obvious satellite topologies because there is no obvious backbone. > > IS-IS, in contrast, insists that L2 overlaps L1. And I’m taking it further and making L2 the union of all L1 areas. I don't see how to do anything analogous in OSPF. You could make everything area 0, but again, that seems like it doesn’t scale. > > If there are better ways, please educate me. I think I understand what you are saying. An IS-IS L1L2 adjacency provides a more natural way for an L1 area to provide transit for inter-area traffic. In OSPF, you’d need to use virtual links. > > >>>> However, in section 5, you assert that ISLs within >>>> a stripe do not change. >>> >>> >>> I didn't mean to say that. Could you please quote the text that suggests that? >>> I’ll rewrite it. >> >> >> This statement in section 5: >> >> Therefore, we propose to group a small number of adjacent >> orbits as an IS-IS L1 area, called a stripe. We assume that for any >> given reliability requirement, there is a small number of orbits that >> can be used to form a stripe that satisfies the reliability >> requirement. >> >> This implied to me that the ISLs within a L1 area are assumed to be relatively stable >> and static but it may be a misunderstanding. > > > > Ah. The distinction here is that I’m assuming that the overall connectedness of the stripe is stable, not that any given ISL is stable. I think I can clarify this a bit. That would be good - you’re saying that the stripe is designed such that the probability of the L1 area partitioning is very low even though there will be inter-area link changes. > > >>>> 3. In section 4, it says all nodes with be L1L2 nodes. >>> >>> >>> >>> That’s correct. >>> >>>> Later, the >>>> usage of area proxy is proposed to reduce the topological information. >>>> So, you'd still have LSPs that very large L2 LSPs including all the >>>> inter-orbit ISLs. Correct? >>> >>> I’m not sure that I understand the question, but I’ll ramble for a bit. >>> >>> The way that Area Proxy works, all nodes within the area (and thus the entire >>> network) are L1L2. However, L2 LSPs from real nodes are never flooded outside >>> of their area. Instead, only the Proxy LSP is flooded at L2. >>> >>> The Proxy LSPs themselves are small: for each area, they will list the areas that >>> they are adjacent to, not individual ISLs. In a ‘dense’ topology where every stripe >>> is adjacent to every other stripe, yes, the LSP will list all areas. This is still very tolerable >>> and would likely be in the 10s of areas. >>> >>> The number of LSPs in L2 are one for each area, plus the L2 LSPs generated inside the local >>> stripe. >>> >>> If we consider a network of 1000 stripes, each with 1000 satellites, the L2 LSDB has >>> 1000 LSPs from areas and 1000 LSPs from the local stripe, so 2000 LSPs. This would >>> seem to be entirely tractable with even modest computational resources. >> >> >> I understand that IS-IS Area Proxy hides the area topology and there is one proxy LSP. >> However, since every node is L1L2 isn’t there at least one L2 ISL on every node and, most likely, >> an L2 neighbor per L2 ISL? Aren’t those all included in the Proxy LSP? It would seem that >> yhis could result in a large and volatile Proxy LSP. > > > > The Proxy LSP does contain the L2 connectivity, but it only contains inter-area adjacencies. Intra-area L2 ISLs are not included. > > >>>> While I don't disagree that area proxy >>>> would reduce the amount of information that every node has to >>>> maintain, you'd still have a lot and since the inter-orbit ISLs >>>> change more frequently than the intra-orbit ISLs, you'd have these >>>> large LSPs changing frequently and being flooded. Do you disagree? >>> >>> >>> That depends on your definition of ‘frequently’. >>> >>> I try to not think about frequency, as that’s highly dependent on the specific network. >>> >>> Rather, I try to think about the impact of any single link change. >>> >>> If an intra-area link changes, then this will be a change to the LSPs for the satellites >>> on either end of the link. It applies to L1 and L2, so in total, there would be four LSPs >>> flooded within a single stripe. This seems tolerable. >>> >>> If an inter-area link changes, then there’s a high likelihood that it is not the only link between >>> the two areas. If that’s the case, then the nodes adjacent on the link will update their L2 LSPs >>> and flood those. That’s one LSP per area in two areas. Entirely tolerable. >>> >>> If we get unlucky and the two areas are no longer adjacent, then both areas will end up >>> updating their Proxy LSPs and flooding those network-wide. Painful, but still tolerable, and >>> a clear reason why we want to have multiple redundant inter-area links if at all possible. >> >> >> This indicates that the proxy LSP only includes one link per attached area via an L1L2 link even if >> there are multiple nodes/ISLs providing connectivity. Is that the case? > > > > You’re right, that’s an optimization that’s above and beyond what’s in the current text. > > As stated, each inter-area L2 adjacency should be listed. So if an inter-area link changes, both of the proxy LSPs that are relevant for that link would change. Again, this seems tolerable. Ok - I guess the L2 link costs stay constant independent of L1 area changes? > > >>>> 4. In section 9, the part of about gateways that aren't interconnected >>>> by the terrestial network requires more discussion as at least it >>>> isn't clear to me. >>> >>> >>> Ok, I’m happy to revise, but it would help if I could understand the confusion. The only thing >>> that’s said there is: >>> >>> If gateways are not interconnected by the terrestrial network, >>> then it may be advisable to use one autonomous system per gateway. >>> >>> This is more of a comment about BGP operations than anything else. >> >> >> The reader may not readily visualize the reasoning. I think I understand >> but wouldn’t put any money on it.. > > > If you prefer, I’m happy to remove that comment. No - I think it is valuable. I was just suggesting to explain why this is the case. Thanks, Acee > > Regards, > Tony > >