Early Review of draft-li-arch-sat-04
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
>
>